- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Fri, 22 May 2015 10:11:29 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hiya, I'm not so sure we have IETF consensus on the right way to balance between widely used named fields vs. individually crafted fields for integer DH. (Just for clarity: for ECDH I think the former approach is fairly clearly where we're at and is fine.) The downside of the latter approach is that if one doesn't check the offered values, then one can be open to attack, and the checks needed can be onerous (e.g. checking primality). Personally, I think the paper goes too far towards recommending site-specific primes be used as we do have a real history of that causing issues in some implementations that omit checks on received values and other implementations that send bad values. (Don't have a reference to hand sorry.) Anyway, I think this'll be fully discussed as part of the TLS1.3 work, and the topic is being discussed on the TLS WG list now, so by the time draft-thomson-http-encryption is baked, I think we'll know what to say in that. Cheers, S. On 22/05/15 09:48, Amos Jeffries wrote: > > The end of Section 4.2 states: > > " > Specifications that rely on an Diffie-Hellman exchange for > determining input keying material MUST either specify the parameters > for Diffie-Hellman (group parameters, or curves and point format) > that are used, or describe how those parameters are negotiated > between sender and receiver. > " > > As has been seen with IKEv1. Having a specification determine explicit > parameters leads directly to it becoming vulnerable when that parameter > group is broken. see <https://weakdh.org/> > > I believe that should be changed to remove the requirement to specify an > exact group. > New text: > " > Specifications that rely on an Diffie-Hellman exchange for > determining input keying material MUST specify how the parameters > for Diffie-Hellman (group parameters, or curves and point format) > that are negotiated between sender and receiver. > " > > Security Considerations should probably also be updated to mention the > possibility of Logjam attack against weak parameter groups. > > Amos > > >
Received on Friday, 22 May 2015 09:12:07 UTC