Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
Yoav Nir writes: > I’m not entirely comfortable with calling something a MUST NOT when all we > have is conjecture, but I have no love and no need of those DH groups. Same here, and it also makes it so that we cannot say our implementation is conforming rfc4307bis, even when we do already have support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to implement algorithms in the new document, but we do also have code to propose the RFC5114 MODP groups, if user configures them to be used. Changing that is of course is very easy to do in implementation, but before this is deployed etc will take some time, and there is change, that some customer has explictly configure RFC5114 2048-bit MODP group in use, and by removing that we suddenly break their existing configuration. It is always annoying to explain to customer why we explictly broke their existing configurations unless there is real security reason for it. Looking that the paper, this only applies to the 1024-bit MODP group in RFC5114, even the paper says that 2048-bit MODP groups are safe, even if they would have same backdoor. We are already downgrading normal 1024-bit MODP group to SHOULD NOT, and this would make it two reasons to make RFC5114 1024-bit MODP group to SHOULD NOT (too short, and might be backdoored), so perhaps the compromize can be to make RFC5114 1024-bit MODP group number 22 to MUST NOT, and keep the groups 23-24 as SHOULD NOTs. Anyways we need to modify the rfc4307bis text and add reference to this paper, as one more reason why groups 22-24 MUST NOT/SHOULD NOT be used. > I don’t believe anyone else depends on these groups (at least in > IPsec), so I’m fine with such a change. I do not think people depend on them, but I assume there is quite a lot of implementations there that can be configured to use them if explictly asked, thus making them MUST NOT will make it so that those implementations will not be conforming rfc4307bis. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
> On 17 Oct 2016, at 19:19, Paul Wouters wrote: > > On Mon, 17 Oct 2016, Yoav Nir wrote: > >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, > > It's a little more than conjecture. > > 1) It has been proven that malicious 1024 bit DH values can be generated > by academia that cannot be independantly discovered. Therefore any > nationstate with access to the same theory and more CPU power could > have done this years ago. Someone can trapdoor 1024-bit values, therefore someone else can trapdoor 2048-bit values. > 2) We have the RFC 5114 values who'se original authors/sponsors are not > disclosing how these were generated. > > 1) + 2) means we cannot know if these values were trapdoor’ed. Yeah, we cannot know. That’s why it’s conjecture. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
Yoav Nir writes: >Someone can trapdoor 1024-bit values, therefore someone else can trapdoor >2048-bit values. Yep, space aliens. However I'm really not too worried about those at the moment. Peter. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
> On 18 Oct 2016, at 13:33, Tero Kivinen wrote: > > Yoav Nir writes: >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, but I have no love and no need of those DH groups. > > Same here, and it also makes it so that we cannot say our > implementation is conforming rfc4307bis, even when we do already have > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to > implement algorithms in the new document, but we do also have code to > propose the RFC5114 MODP groups, if user configures them to be used. I don’t think that’s the right way to interpret compliance with RFC4307bis. If you can configure your implementation to support only algorithms that are MUST, SHOULD, or MAY in the document, then you can configure your implementation to comply with 4307bis. I don’t think implementation compliance requires pulling out code. Our implementation allows the user to key in long hex strings to construct MODP groups that are not available out of the box. With your interpretation we can never be compliant because they can always make up their own 512-bit group and add that to the available groups. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
Yoav Nir writes: > > Same here, and it also makes it so that we cannot say our > > implementation is conforming rfc4307bis, even when we do already have > > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to > > implement algorithms in the new document, but we do also have code to > > propose the RFC5114 MODP groups, if user configures them to be used. > > I don’t think that’s the right way to interpret compliance with > RFC4307bis. If you can configure your implementation to support only > algorithms that are MUST, SHOULD, or MAY in the document, then you > can configure your implementation to comply with 4307bis. I don’t > think implementation compliance requires pulling out code. When rfc4307bis says MUST NOT do DES, and MUST NOT do 768-bit MODP, I assume that to be conforming to that document, user is not able to configure DES with 768-bit MODP group. Of course MUST NOTs are difficult as it is really hard to show where in your code you implement this specific MUST NOT (yes, there was one customer asking us to point out where in code we implement each MUST NOTs). > Our implementation allows the user to key in long hex strings to > construct MODP groups that are not available out of the box. With > your interpretation we can never be compliant because they can > always make up their own 512-bit group and add that to the available > groups. That is different issue, as this is SHOULD feature in the RFC7296: parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman parameters (the generator, modulus, and exponent lengths and values) for new Diffie-Hellman groups. Implementations SHOULD provide a management interface through which these parameters and the associated Transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. Also there is nothing in the rfc4307bis saying that that is MUST NOT... On the otherhand if someone uses that interface to configure the 768-bit MODP group 1, then he is going against MUST NOT in rfc4307bis, and his system is longer conforming... It might be good idea to limit that interface so it will not allow any groups which are shorter than 1024-bits, just so users cannot do stupid things... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Yet another RFC-5114 attack
https://eprint.iacr.org/2016/995.pdf Several recent standards, including NIST SP 800- 56A and RFC 5114, advocate the use of “DSA” parameters for Diffie-Hellman key exchange. While it is possible to use such parameters securely, additional validation checks are necessary to prevent well-known and potentially devastating attacks. In this paper, we observe that many Diffie-Hellman implementations do not properly validate key exchange inputs. Combined with other protocol properties and implementation choices, this can radically decrease security. We measure the prevalence of these parameter choices in the wild for HTTPS, POP3S, SMTP with STARTTLS, SSH, IKEv1, and IKEv2, finding millions of hosts using DSA and other non-“safe” primes for Diffie-Hellman key exchange, many of them in combination with potentially vulnerable behaviors. We examine over 20 open-source cryptographic libraries and applications and observe that until January 2016, not a single one validated subgroup orders by default. This paper also actually understood the difficulties of IKE scanning! And kudos to the authors for looking into so much deployment and open source software! Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
On Tue, Oct 18, 2016 at 3:33 AM, Tero Kivinen wrote: > Yoav Nir writes: >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, but I have no love and no need of those DH groups. > > Same here, and it also makes it so that we cannot say our > implementation is conforming rfc4307bis, even when we do already have > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to > implement algorithms in the new document, but we do also have code to > propose the RFC5114 MODP groups, if user configures them to be used. > > Changing that is of course is very easy to do in implementation, but > before this is deployed etc will take some time, and there is change, > that some customer has explictly configure RFC5114 2048-bit MODP group > in use, and by removing that we suddenly break their existing > configuration. In sane protocols the default MTI ciphersuite is always ready to be used for exactly this reason. IKE's extensively flexible configuration knobset was not a good idea for this reason. > > It is always annoying to explain to customer why we explictly broke > their existing configurations unless there is real security reason for > it. Looking that the paper, this only applies to the 1024-bit MODP > group in RFC5114, even the paper says that 2048-bit MODP groups are > safe, even if they would have same backdoor. > > We are already downgrading normal 1024-bit MODP group to SHOULD NOT, > and this would make it two reasons to make RFC5114 1024-bit MODP group > to SHOULD NOT (too short, and might be backdoored), so perhaps the > compromize can be to make RFC5114 1024-bit MODP group number 22 to > MUST NOT, and keep the groups 23-24 as SHOULD NOTs. This seems reasonable to me. > > Anyways we need to modify the rfc4307bis text and add reference to > this paper, as one more reason why groups 22-24 MUST NOT/SHOULD NOT be > used. > >> I don’t believe anyone else depends on these groups (at least in >> IPsec), so I’m fine with such a change. > > I do not think people depend on them, but I assume there is quite a > lot of implementations there that can be configured to use them if > explictly asked, thus making them MUST NOT will make it so that those > implementations will not be conforming rfc4307bis. That's sort of the point. We want these implementations to NOT support these groups, just as RC4 die-die-die meant TLS implementations no longer support RC4. > -- > kivi...@iki.fi > > ___ > saag mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
On Tue, 18 Oct 2016, Yoav Nir wrote: It's a little more than conjecture. 1) It has been proven that malicious 1024 bit DH values can be generated by academia that cannot be independantly discovered. Therefore any nationstate with access to the same theory and more CPU power could have done this years ago. Someone can trapdoor 1024-bit values, therefore someone else can trapdoor 2048-bit values. 2) We have the RFC 5114 values who'se original authors/sponsors are not disclosing how these were generated. 1) + 2) means we cannot know if these values were trapdoor’ed. Yeah, we cannot know. That’s why it’s conjecture. conjecture: 1. an opinion or conclusion formed on the basis of incomplete information. I have complete information for "one cannot detect trapdoors without knowing seed" Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
Paul, It's been over 8 years since this RFC was published, and I have not looked at it since then. My recollection is that we wrote 5114 because an IPsec developer approached me and said that he wanted to support these groups in a product. He said that he wanted test vectors for the groups, consistent with what we have done for many other algs. I persuaded Matt to generate the RFC because it was a relatively easy task a good way for Matt to get acquainted with the RFC process. As to your question, I have no info about how the NIST DH values were generated. However, I do agree with Yoav and Tero that it seems unduly prejudicial to declare these to be a MUST NOT. The fact that one can generate trap-doored DH values that cannot be detected is not the same as having proof that a given set of values have been generated in that fashion. Moreover, if one interprets a MUST NOT in this context to mean that an implementation supporting any of these groups is non-compliant, then that unfairly penalizes existing implementations, as Tero noted. Moreover, if the concern raised by the paper (which I have read) is with MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits that criteria (section 2.1). I have not tracked the status of these NIST groups re evaluation criteria like FIPS 140-2. If these groups are approved for use in products evaluated under that FIPS (I don't know if they are), deprecating them creates a possible conundrum for vendors who want to comply with RFCs and with FIPS evaluation criteria. Thus I suggest a less dramatic response than declaring all of the groups in 5114 to be MUST NOT. I'm not a vendor of any crypto products (these days), and I've never been a crypto mathematician. So my views are based only on what I recall about the creation of 5114 and about IETF crytpo standards practices in general. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
New paper “Measuring small subgroup attacks against Diffie-Hellman” https://eprint.iacr.org/2016/995.pdf “Cryptographic recommendations from standards committees are often too weak or vague” “However, the tangle of RFCs and standards attempting to define current best practices in key generation and parameter sizing do not paint a clear picture, and instead describe complex combinations of approaches and parameters, exposing the fragility of the cryptographic ecosystem. As a result, developers often forget or ignore edge cases, leaving many implementations of Diffie-Hellman too close to vulnerable" “As we show in this paper, finite-field based Diffie-Hellman has many edge cases that make its correct use difficult, and which occasionally arise as bugs at the protocol level.” “As a concrete recommendation, modern Diffie-Hellman implementations should prefer elliptic curve groups over safe curves with proper point validation.” /John On 18/10/16 16:47, "IPsec on behalf of Stephen Kent" wrote: >Paul, > >It's been over 8 years since this RFC was published, and I have not >looked at it since then. My recollection is that we wrote 5114 because >an IPsec developer approached me and said that he wanted to support >these groups in a product. He said that he wanted test vectors for the >groups, consistent with what we have done for many other algs. I >persuaded Matt to generate the RFC because it was a relatively easy task >a good way for Matt to get acquainted with the RFC process. > >As to your question, I have no info about how the NIST DH values were >generated. However, I do agree with Yoav and Tero that it seems unduly >prejudicial to declare these to be a MUST NOT. The fact that one can >generate trap-doored DH values that cannot be detected is not the same >as having proof that a given set of values have been generated in that >fashion. Moreover, if one interprets a MUST NOT in this context to mean >that an implementation supporting any of these groups is non-compliant, >then that unfairly penalizes existing implementations, as Tero noted. >Moreover, if the concern raised by the paper (which I have read) is with >MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits >that criteria (section 2.1). > >I have not tracked the status of these NIST groups re evaluation >criteria like FIPS 140-2. If these groups are approved for use in >products evaluated under that FIPS (I don't know if they are), >deprecating them creates a possible conundrum for vendors who want to >comply with RFCs and with FIPS evaluation criteria. Thus I suggest a >less dramatic response than declaring all of the groups in 5114 to be >MUST NOT. > >I'm not a vendor of any crypto products (these days), and I've never >been a crypto mathematician. So my views are based only on what I recall >about the creation of 5114 and about IETF crytpo standards practices in >general. > >Steve > >___ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
