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

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

On Mon 2014-10-27 07:37:01 -0400, Henrick Hellström wrote:
> It does however strike me as odd that, as a consequence, a named FFDHE 
> compatible server, would still be allowed to negotiate DHE cipher suites 
> with legacy clients that do not even implement RFC 4492, but not with 
> legacy clients that implement DHE in the exact same way, but also 
> support a few weak elliptic curves.

hm, yes, i agree that this is a bad outcome, and as of -02 that does
appear to be the consequence of the draft.  Thanks for pointing this
out, Henrick.

To be clear, i think the problem is:

 * a compatible server might see a client send a DHE ciphersuite and the
   NamedCurves extension, but with at least one identified NamedCurve
   that the server doesn't know.

 * In this case, the server cannot distinguish the following two peers:

    A) the client implements this draft, but only implements an unusual
       FFDHE that the server has never heard of.

    B) the client does not implement with this draft and happens to
       implement an elliptic curve that the server has never heard of.

 * The right logic here is that the server SHOULD NOT select DHE for
   client A, but MAY select DHE for client B, as when interoperating
   with any other legacy client implementation.  But the server can't
   distinguish between these cases.


I think there needs to be explicit signalling from the client that it
understands known FFDHE groups, so that a server can distinguish between
these cases.

I see three ways to achieve this goal:

 0) reintroduce an explicit (contentless) ClientHello extension that
    means "i understand FFDHE named groups"

 1) allocate a single codepoint in the named groups registry that means
    "i understand FFDHE named groups" but is not a negotiable group

 2) carve out a range of codepoints in the named groups registry that
    will be used only for FFDHE named groups (and no other codepoints in
    that registry will have FFDHE).  This way, servers can recognize a
    named FFDHE group, even if they don't know what it is.

(0) seems like a simple approach, though it introduces a bit of redundancy
that could cause weirdness -- what does it mean if the ClientHello
extension is not present, but an FFDHE group exists in the NamedCurves
extension, for example?

(1) smells a lot like the SCSV approach we've been trying (and failing)
to avoid using in other contexts, though it happens in NamedCurves,
instead of in the ciphersuite list.  I'd really rather avoid this kind
of hackery.

(2) seems like it might be the simplest approach.  For example, if the
value is within [256,287]) then the NamedCurve is FFDHE.  This wouldn't
be the first time that an IANA registry had range registration
procedures like this, see e.g.  ARP Hardware Types:

https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2

It does place a smaller permanent cap on the number of FFDHE groups we
might ever name, but i don't think a limit of 32 FFDHE groups (as in the
proposed range above) is particularly troubling.  I expect we want
fewer, stronger groups, not more.

Any thoughts or preferences?

        --dkg