Re: [Ace] How to specify DTLS MTI in COAP-EST
We had that discussion at the SUIT hackathon earlier this week, as well. To get actual interoperability there, of course, every test pair needs to decide between P-256 and 25519 (and, maybe, use hash-based instead; but that is more appropriate for firmware update than for other uses). The general observation was that we are seeing a much slower displacement of P-256 by 25519 than we would have expected, say, a year ago. So, indeed, RFC 7925 is continuing to describe the current situation. We can simply acknowledge that status quo. We can also express some normative intent to accelerate the transition. Or we can express an expectation that it will accelerate, without actually expressing normative intent. Either one could be anchored at a specific date (say, 25519 becomes MTI from 2020). As I said at the IoT-dir meeting in London, this is really the discussion I would like to see now across all IoT groups. What do we want? Grüße, Carsten > On Jun 7, 2018, at 23:26, Michael Richardson wrote: > > > Eric Rescorla wrote: >> TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so >> you should just use words if you want to convey these points. > >> With that said, I don't really understand the objective here: we're >> generally moving towards the CFRG curves, so what's the reasoning for the >> P256 MUST and why do you think that will change. > > Because current generation of hardware and TPM modules has definite support > for P256, and while some of the hardware assist out there can accelerate CFRG > curves as well or better: > a) it's not universally true. > b) it takes time to get the new code through a FIPS process. > > So, we want to say, P256 is if you must, and CFRG if you can on the > constrained device. > > On a non-constrained CA side, P256 becomes a MUST because one needs to > support the old devices, and CFRG becomes a MUST just as soon as one > can get the code through the right processes. > > In any case, 7925 says EXACTLY this, so we are happy, and do not want to > repeat things. > >> wrote: > >>> >>> Hannes Tschofenig wrote: why don't you just reference https://tools.ietf.org/html/rfc7925? >>> >>> Ignorance :-) >>> Thank you, I think that we will reference it then; >>> >>> Section 4.4 includes: >>> >>> At the time of writing, the >>> recommended curve is secp256r1, and the use of uncompressed points >>> follows the recommendation in CoAP. Note that standardization for >>> Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for >>> this curve will likely be required in the future. >>> >>> which is what we want to say anyway. >>> I am not a big fan of making all sorts of different crypto recommendations in our specs that differ slightly. >>> >>> -- >>> ] Never tell me the odds! | ipv6 mesh >>> networks [ >>> ] Michael Richardson, Sandelman Software Works| network >>> architect [ >>> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on >>> rails[ >>> >>> >>> ___ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >>> > >> >> Alternatives: > >> > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Eric Rescorla wrote: > TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so > you should just use words if you want to convey these points. > With that said, I don't really understand the objective here: we're > generally moving towards the CFRG curves, so what's the reasoning for the > P256 MUST and why do you think that will change. Because current generation of hardware and TPM modules has definite support for P256, and while some of the hardware assist out there can accelerate CFRG curves as well or better: a) it's not universally true. b) it takes time to get the new code through a FIPS process. So, we want to say, P256 is if you must, and CFRG if you can on the constrained device. On a non-constrained CA side, P256 becomes a MUST because one needs to support the old devices, and CFRG becomes a MUST just as soon as one can get the code through the right processes. In any case, 7925 says EXACTLY this, so we are happy, and do not want to repeat things. > wrote: >> >> Hannes Tschofenig wrote: >> > why don't you just reference https://tools.ietf.org/html/rfc7925? >> >> Ignorance :-) >> Thank you, I think that we will reference it then; >> >> Section 4.4 includes: >> >> At the time of writing, the >> recommended curve is secp256r1, and the use of uncompressed points >> follows the recommendation in CoAP. Note that standardization for >> Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for >> this curve will likely be required in the future. >> >> which is what we want to say anyway. >> >> > I am not a big fan of making all sorts of different crypto >> > recommendations in our specs that differ slightly. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works| network >> architect [ >> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on >> rails[ >> >> >> ___ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> > > Alternatives: > -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so you should just use words if you want to convey these points. With that said, I don't really understand the objective here: we're generally moving towards the CFRG curves, so what's the reasoning for the P256 MUST and why do you think that will change. -Ekr On Thu, Jun 7, 2018 at 10:41 AM, Michael Richardson wrote: > > Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? > > Ignorance :-) > Thank you, I think that we will reference it then; > > Section 4.4 includes: > > At the time of writing, the > recommended curve is secp256r1, and the use of uncompressed points > follows the recommendation in CoAP. Note that standardization for > Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for > this curve will likely be required in the future. > > which is what we want to say anyway. > > > I am not a big fan of making all sorts of different crypto > > recommendations in our specs that differ slightly. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on > rails[ > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Hannes Tschofenig wrote: > why don't you just reference https://tools.ietf.org/html/rfc7925? Ignorance :-) Thank you, I think that we will reference it then; Section 4.4 includes: At the time of writing, the recommended curve is secp256r1, and the use of uncompressed points follows the recommendation in CoAP. Note that standardization for Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for this curve will likely be required in the future. which is what we want to say anyway. > I am not a big fan of making all sorts of different crypto > recommendations in our specs that differ slightly. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Russ Housley wrote: > These words were first used by IPsec; see RFC 4307. They have gained > broader acceptance. I see no problem just using them here. Yes, but they aren't in an RFC2119-like document that we can simply cite, and I'm not sure if the TLS reviewers will like them. Ben doesn't like them for instance. I would probably just write: SHOULD+/SHOULD-/MUST- are used in the same way as in RFC8247 >> On Jun 6, 2018, at 7:32 PM, Michael Richardson wrote: >> >> >> In draft-ietf-ace-coap-est, we would like to specify some mandatory to >> implement algorithms for DTLS. >> >> We write: >> The mandatory cipher suite for DTLS in EST-coaps is >> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the >> mandatory-to-implement cipher suite in CoAP. >> >> Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve >> is equivalent to the NIST P-256 curve. >> >> And this is fine for now, but we'd like to signal that Curve25519 should be >> considered as an alternative, but we don't want to make it a MUST *today*, >> and we don't want to force implementations 15 years down the road that have >> it to include secp256r1. >> >> IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc8247/ >> which include language like: >> >> SHOULD+ This term means the same as SHOULD. However, it is likely >> that an algorithm marked as SHOULD+ will be promoted at >> some future time to be a MUST. >> >> SHOULD- This term means the same as SHOULD. However, an algorithm >> marked as SHOULD- may be deprecated to a MAY in a future >> version of this document. >> >> MUST- This term means the same as MUST. However, it is expected >> at some point that this algorithm will no longer be a MUST >> in a future document. Although its status will be >> determined at a later time, it is reasonable to expect that >> if a future revision of a document alters the status of a >> MUST- algorithm, it will remain at least a SHOULD or a >> SHOULD- level. >> >> I don't think TLS has done this... maybe TLS plans to. >> We think that we'd like to use SHOULD+ for Curve25519 and MUST- for >> secp256r1, but we aren't sure that the WG will like us to use so many >> words as IPsec to say so. >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works| network architect [ >> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ >> >> >> ___ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Olaf Bergmann wrote: > Michael Richardson writes: >> Curve25519 should be considered as an alternative > As we had this discussion at IETF-101 regarding the profile coap_dtls: > What where your reasoning for Curve25519? (Especially vs. Ed25519?) AFAIK, Curve25519 is about the PFS/key-agreement. Ed25519 is about authentication of the end-points, and depends upon what's in the certificates (if any are used) to validate the end points. CoAP-EST does not say anything actually about authentication; i.e. how we get the Secure Transport. It's out of scope for this document. (But, in scope for draft-ietf-6tisch-dtsecure-zerotouch-join ) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
In products crypto does not change that fast given the lifetime of IoT devices and the hardware support for it. Our customers are asking for NIST certified crypto. Ciao Hannes -Original Message- From: Carsten Bormann [mailto:c...@tzi.org] Sent: 07 June 2018 18:40 To: Hannes Tschofenig Cc: Russ Housley; Michael Richardson; ace@ietf.org Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST On Jun 7, 2018, at 18:30, Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? That describes the status of mid-2016. Can we do something forward-looking? Grüße, Carsten IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
On Jun 7, 2018, at 18:30, Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? That describes the status of mid-2016. Can we do something forward-looking? Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Hi Russ, Hi Michael, why don't you just reference https://tools.ietf.org/html/rfc7925? I am not a big fan of making all sorts of different crypto recommendations in our specs that differ slightly. Ciao Hannes PS: Next time someone suggests the use of a new crypto algorithm I will demand that they also implement one themselves. -Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Russ Housley Sent: 07 June 2018 15:55 To: Michael Richardson Cc: ace@ietf.org Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST Michael: These words were first used by IPsec; see RFC 4307. They have gained broader acceptance. I see no problem just using them here. Russ > On Jun 6, 2018, at 7:32 PM, Michael Richardson wrote: > > > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. > > We write: > The mandatory cipher suite for DTLS in EST-coaps is > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the > mandatory-to-implement cipher suite in CoAP. > > Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve > is equivalent to the NIST P-256 curve. > > And this is fine for now, but we'd like to signal that Curve25519 > should be considered as an alternative, but we don't want to make it a > MUST *today*, and we don't want to force implementations 15 years down > the road that have it to include secp256r1. > > IPsec(ME) has published things like: > https://datatracker.ietf.org/doc/rfc8247/ > which include language like: > > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. > > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. > > MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level. > > I don't think TLS has done this... maybe TLS plans to. > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, but we aren't sure that the WG will like us to use so many > words as IPsec to say so. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works| network architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Michael: These words were first used by IPsec; see RFC 4307. They have gained broader acceptance. I see no problem just using them here. Russ > On Jun 6, 2018, at 7:32 PM, Michael Richardson wrote: > > > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. > > We write: > The mandatory cipher suite for DTLS in EST-coaps is > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the > mandatory-to-implement cipher suite in CoAP. > > Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve > is equivalent to the NIST P-256 curve. > > And this is fine for now, but we'd like to signal that Curve25519 should be > considered as an alternative, but we don't want to make it a MUST *today*, > and we don't want to force implementations 15 years down the road that have > it to include secp256r1. > > IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc8247/ > which include language like: > > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. > > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. > > MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level. > > I don't think TLS has done this... maybe TLS plans to. > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, but we aren't sure that the WG will like us to use so many > words as IPsec to say so. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works| network architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace signature.asc Description: Message signed with OpenPGP ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
On Wed, Jun 06, 2018 at 07:32:13PM -0400, Michael Richardson wrote: > > In draft-ietf-ace-coap-est, we would like to specify some mandatory to > implement algorithms for DTLS. > > We write: >The mandatory cipher suite for DTLS in EST-coaps is >TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the >mandatory-to-implement cipher suite in CoAP. > >Additionally, the curve secp256r1 MUST be supported [RFC4492]; this curve >is equivalent to the NIST P-256 curve. > > And this is fine for now, but we'd like to signal that Curve25519 should be > considered as an alternative, but we don't want to make it a MUST *today*, > and we don't want to force implementations 15 years down the road that have > it to include secp256r1. > > IPsec(ME) has published things like: https://datatracker.ietf.org/doc/rfc8247/ > which include language like: > >SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. > >SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. > >MUST- This term means the same as MUST. However, it is expected > at some point that this algorithm will no longer be a MUST > in a future document. Although its status will be > determined at a later time, it is reasonable to expect that > if a future revision of a document alters the status of a > MUST- algorithm, it will remain at least a SHOULD or a > SHOULD- level. Unfortunately, I'm not a big fan of the "+/-" variants of RFC 2119 keywords. It seems more clear to me to actually write out in prose the current situation and future expectations. So, if you do end up going this route, please ensure that the shepherd writeup includes a justification of why it was chosen. -Ben signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] How to specify DTLS MTI in COAP-EST
Hello Michael, Michael Richardson writes: > Curve25519 should be considered as an alternative As we had this discussion at IETF-101 regarding the profile coap_dtls: What where your reasoning for Curve25519? (Especially vs. Ed25519?) Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
