Re: [saag] Possible backdoor in RFC 5114

[Yoav Nir <[e-mail]>]

Hi, Watson.

On 6 Oct 2016, at 18:56, Watson Ladd <[e-mail]> wrote:

> https://tools.ietf.org/html/rfc5114
> 
> Let's review some publicly known facts:
> 
> 1) BBN is a defense contractor
> 
> 2) The NSA subverts crypto standards
> 
> 3) It is possible to design primes so the discrete log problem is easy
> 
> 4) The primes in RFC 5114 are not generated in verifiable manner: it
> is possible they
> are hidden SNFS primes.
> 
> At minimum we should obsolete RFC 5114 in favor of primes generated in
> a verifiable manner. The fact that there already were primes for IKE
> use makes me wonder why this was even needed in the first place.
> 

RFC 5114 is an Informational document published by two employees (at the time) of BBN as individuals. As the boilerplate says, “it does not specify an Internet standard of any kind”.

IANA numbers have been assigned to them for IKE, but they have not seen widespread use.  In TLS they are all but unknown, and recent work is deprecating the use of DHE with explicit parameters anyway.

The soon-to-be published successor to RFC 4307 (algorithm guidance for IKE - [1]) makes them “SHOULD NOT”.

It has never been explained in what way a 2048-bit MODP Group with 224-bit Prime Order Subgroup is better than a 2048-bit MODP Group without one.  Consequently everyone uses the regular 2048-bit MODP from RFC 3526 ([2]) if they’re not using ECDHE groups.

The RFC is effectively not in use. I don’t see any value in obsoleting it by writing a new RFC with more MODP groups that nobody wants. We could move it to Historic.

Yoav
 
[1] https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-14 <https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-14>
[2] https://tools.ietf.org/html/rfc3526 <https://tools.ietf.org/html/rfc3526>