Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt

[Daniel Kahn Gillmor <[e-mail]>]

Hi Peter, thanks for the quick review.

On 10/11/2014 04:19 AM, Peter Gutmann wrote:
> Daniel Kahn Gillmor <[e-mail]> writes:
> 
>> I'd appreciate any comments or suggestions, and particularly review related
>> to the IANA considerations would be great.
> 
> It still doesn't include the widely-deployed IPsec groups (RFC 3526) that I
> asked for last time round, or the RFC 5114 groups which specifically mention
> use in TLS in their RFC.

yes, and that's a deliberate choice, as documented (perhaps not well
enough?) in the draft under "Choice of Groups".

I don't think we should include many groups (this leads to interop
issues and fingerprinting issues), so just adding to the list seems like
a bad idea.

Some of the MODP groups (768, 1024, 1536 at least) are also smaller than
we should be explicitly supporting in updated tools, so i don't think
re-blessing them into another standard is a good idea.

And if there is some fancy attack that needs expensive pre-computation
to work against a targeted group, we shouldn's expose both TLS and IPSEC
because they're sharing groups.

One counterargument i'm aware of is that systems that want to support
both sets of groups would need to have a larger table of known moduli.
So perhaps the argument is that extremely memory-constrained devices
running both TLS and IPSec (or TLS with SRP) could share a table of
known moduli to reduce RAM consumption?  I'm not convinced that this is
particularly important for modern hardware, or that there are many
deployments that meet this scope anyway.

The 5114 groups are small, have unusual generators, and the moduli don't
appear to be safe primes, so it's difficult to know if a peer is forcing
you into a small subgroup with their share -- am i mistaken on that?

We had a discussion about the use of e-derived safe primes instead of
pi-derived safe primes in Toronto, and no one seemed to think that the
groups currently proposed were any worse than the MODP groups.

So i'm not inclined to change this, unless there is a stronger argument
or more widespread opposition to it.

Should i add more of the above detail anywhere in the draft to make it
clear why it's set up this way?

	--dkg