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

[Ilari Liusvaara <[e-mail]>]

On Mon, Oct 27, 2014 at 12:07:00PM +0100, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-10-27 at 11:58 +0100, Henrick Hellström wrote:
> >
> > FWIW, the real problem here is RFC 4492. There was no ambiguity in TLS 
> > 1.0, because the ServerKeyExchange could only contain two kinds of 
> > messages, one with two large integers (a ServerRSAParams) or one with 
> > three large integers (a ServerDHParams). RFC 4492 introduced the 
> > ambiguity. Can anyone think of a way to fix it, without forcing Named 
> > FFDHE compatible servers to negotiate RSA cipher suites instead of DHE 
> > cipher suites with legacy clients? Is that even a good idea? (That was a 
> > rhetorical question.)
> 
> A way to fix that for the ffdhe draft would be to introduce a two-byte
> type that is on purpose large (eg. values like 0xff 0xfa).

Basically, you want to:
1) ECDHE SKE to not be interpretable as FFDHE SKE.
2) FFDHE SKE to blow up when interpretted as ECDHE SKE.
3) FFDHE SKE to blow up when interpretted as DHE SKE (including legacy software).


If the first byte of FFDHE SKE has to be 00, that takes care of 1) and 2),
because first byte of ECDHE SKE is the curve type, and curve type 0 is
not valid.

3) Is nastier issue. AFAICT, with such misinterpretation, not even session_hash
will save you.

One way (not necressarily good) would be to encode ServerDHParams as
00 01 00 NOT(grpid). If one tries to parse this as DHE, one gets p=0 and length
of g being ~65,000 bytes (pretty certainly overflowing the message).


-Ilari