Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)
On 13/10/16 13:27, Yoav Nir wrote: > Hi, Stephen > >> >> - Wouldn't it be good to encourage minimising re-use of public >> values for multiple key exchanges? As-is, the text sort-of >> encourages use for "many key exchanges" in section 4. > > I don’t think so. Fair enough, though when I said "minimise" I didn't mean "never re-use." But all you say below is correct, so not that big a deal, but I do think it'd be better to explicitly encourage implementers to roll their private values as often as makes sense in their situation. S. > Re-use reduces the computation cost of an IKE > Responder (or TLS server) without sacrificing security. There was > some discussion of this in CFRG, but I see that it didn’t make it > into RFC 7748, so all I can find is some StackExchange question > ([1]). > > It does make the static keypair valuable. It is definitely not a good > idea to store the private key on-disk and keep it forever, but > generating a new key once in a while and discarding the old key is > usually a good compromise there. > > Anyway key-pair reuse is established practice. Using constant-time > implementations is essential to making this practice safe, and the > Security Considerations sections says just that. > > Yoav > > [1] > http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-public-key > smime.p7s Description: S/MIME Cryptographic Signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)
Thanks Tero and sorry for forgetting:-) Cheers, S. On 13/10/16 13:04, Tero Kivinen wrote: > Stephen Farrell writes: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ipsecme-safecurves-05: Yes >> >> -- >> COMMENT: >> -- >> - Sorry if I'm forgetting how we handle this in IPsec, >> but is an implementation of this RFC expected to support >> both curves? I think it'd be ok to say that 25519 is a >> MUST for folks doing, this but that 448 is optional. I'm >> also fine if we mean that implementing this means you >> have to support both btw but you don't say (here) that >> that's the case. > > In IPsec we do not specify any requirement levels in the actual > algorithm documents. The algorithm documents just allocate the IANA > numbers and specify how they algorithms are used. > > Then we have separate documents (new versions soon to be in front of > IESG) specifying the actual mandatory to implement algorithms. > > Whether some implementation supports this new RFC is something that > does not have well define answer, as people could say they implement > this RFC if they support one or other, or both curves. Usually people > are just saying they support algorithm RFC if they support one > algorithm from there. I.e., vendors usually say they support RFC2451, > even if they only support 3DES from there, and might not support > CAST-128, RC5, IDEA and Blowfish. > > Anyways the mandatory to implement ciphers are specified in the > rfc4307bis [1] and rfc7321bis [2]. > > These curves are not mentioned there, so they are still going to be > MAY. When we are going to update 4307bis again then we are most likely > going to make them SHOULD+ or even MUST (if there is enough > implementations actually implementing them at that point). > > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ > [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/ > smime.p7s Description: S/MIME Cryptographic Signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)
Stephen Farrell writes: > Stephen Farrell has entered the following ballot position for > draft-ietf-ipsecme-safecurves-05: Yes > > -- > COMMENT: > -- > - Sorry if I'm forgetting how we handle this in IPsec, > but is an implementation of this RFC expected to support > both curves? I think it'd be ok to say that 25519 is a > MUST for folks doing, this but that 448 is optional. I'm > also fine if we mean that implementing this means you > have to support both btw but you don't say (here) that > that's the case. In IPsec we do not specify any requirement levels in the actual algorithm documents. The algorithm documents just allocate the IANA numbers and specify how they algorithms are used. Then we have separate documents (new versions soon to be in front of IESG) specifying the actual mandatory to implement algorithms. Whether some implementation supports this new RFC is something that does not have well define answer, as people could say they implement this RFC if they support one or other, or both curves. Usually people are just saying they support algorithm RFC if they support one algorithm from there. I.e., vendors usually say they support RFC2451, even if they only support 3DES from there, and might not support CAST-128, RC5, IDEA and Blowfish. Anyways the mandatory to implement ciphers are specified in the rfc4307bis [1] and rfc7321bis [2]. These curves are not mentioned there, so they are still going to be MAY. When we are going to update 4307bis again then we are most likely going to make them SHOULD+ or even MUST (if there is enough implementations actually implementing them at that point). [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/ -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-safecurves-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ -- COMMENT: -- - Wouldn't it be good to encourage minimising re-use of public values for multiple key exchanges? As-is, the text sort-of encourages use for "many key exchanges" in section 4. - Sorry if I'm forgetting how we handle this in IPsec, but is an implementation of this RFC expected to support both curves? I think it'd be ok to say that 25519 is a MUST for folks doing, this but that 448 is optional. I'm also fine if we mean that implementing this means you have to support both btw but you don't say (here) that that's the case. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
