From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: tls@ietf.org
In-Reply-To: <544E2E5D.4000805@streamsec.se>
References: <20141011044948.27553.93984.idtracker@ietfa.amsl.com>
 <5438B82B.6090600@fifthhorseman.net> <544BD3BF.9030702@streamsec.se>
 <1682594903.63043.1414266713793.JavaMail.zimbra@redhat.com>
 <544C1BC3.5060204@streamsec.se>
 <1749574094.84536.1414307373087.JavaMail.zimbra@redhat.com>
 <544E0682.30804@streamsec.se>
 <1414405551.2543.8.camel@dhcp-2-127.brq.redhat.com>
 <544E254A.3020501@streamsec.se>
 <1414408020.2543.13.camel@dhcp-2-127.brq.redhat.com>
 <544E2E5D.4000805@streamsec.se>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1
 (x86_64-pc-linux-gnu)
Date: Mon, 27 Oct 2014 14:20:43 -0400
Message-ID: <874mupwf0k.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fjo3iueH9lLkQXoP4HxFj9uv4D8
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt
Precedence: list

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon 2014-10-27 07:37:01 -0400, Henrick Hellstr=C3=B6m wrote:
> It does however strike me as odd that, as a consequence, a named FFDHE=20
> compatible server, would still be allowed to negotiate DHE cipher suites=
=20
> with legacy clients that do not even implement RFC 4492, but not with=20
> legacy clients that implement DHE in the exact same way, but also=20
> 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-pa=
rameters-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

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJUToz8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcNIQQAND6cpL5EV/NW6V11OvW2p+N
qzZM6Xp0Dd3zu7H4b79X5q/m+814T2GMywVZnKA9Q/TOl1BA/5oyuUqof/UlXZ7V
ifxSCQF8WiA024F9uI+y9c6e21kckNbP2LQiF41jjE2kWzmhxgIHGNjjvUn/rMkI
3Nm+gFlJw1I7D/0sT0O9EkyjKBCuPCmuHBTOocw8usTtuYXZ2lN9w65QVs7Imp+w
2XFE4Gg3HRx8GbEoDQIW1H7mhgtksQrAQ7v38DfMmfD4IopNo9vhNAVV7o4hk6TS
mjCWuLcN3kZgkioE6ydt0Gbwy+FBvTyMzwHLJ4TpNhns1sf2139eu1Zpy21XWcGi
QvtlbagSQIEzEbxi9X4K8ZZa5ccwvkdihoBJJpYw/pFumMSbsa2zH9mQn99kJleq
YJ/dYdOPcCVLJb9tVks4oMenJY2VyCJ+xLNwBjHHJYTmf/6s3Fqt79hqBbqa8xdy
M5PBwTy9NsYtjKlYvOa06/fNmIBVp0+rWCVn5GO35x2CyRYi33O1Ps7rZ5yxgOCX
ajqYBiWGEcaiMiuwXaNU9D+9lB2HQajIMSfz4itX1LTErFkgk+uNMK3zM5fOMzl+
sGJPusUp8qTcmTfA5j4YO7D/txgX1cYw3LtZ42Dee6lBA4E0FQ2xLS6g6e3t2snz
QOBR3cudVN/d0j6k0o1q
=MBQH
-----END PGP SIGNATURE-----
--=-=-=--