Re: [TLS] Another IRINA bug in TLS

[Dan Brown <[e-mail]>]

In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the
medium term recommendation to avoid fixed-prime DHE groups seems to conflict
with the current direction TLS is taking towards named only groups.  

I gather that TLS is still planning keep DHE around (as a supplement to
ECDHE).   So, should TLS stick to its current approach of using named DHE
groups, just with larger key sizes, or should it follow the recommendation
above of allowing custom DHE groups?  

Maybe this is question for CFRG, since it can pertain to multiple WGs?

If TLS opts for the latter, to bring back custom DHE parameters per the
recommendation above, then it seems that TLS should expand on the simple TLS
1.2 ServerDHParams, by including the order of the generator, and probably
including some kind of seed to a PRF (making them similar to the old custom
ECDHE parameters).  

Note that ECDHE and DHE largely share the issue of fixed parameters are
affected by a pre-computation across multiple keys.  

Choosing a larger key size is the most efficient and simple remedy against
these pre-computations.  

Allowing custom groups provides a second defense against the such
pre-computation, but supporting custom groups creates other problems.  Peers
need to verify the custom groups, and the groups need to be generated.  The
computation and communication spent on verifying custom groups could perhaps
be better spent on using larger fixed groups.

My preference is to recommend larger, vetted, fixed groups (e.g. at least
2048-bit DH and 256-ish-bit ECDHE) just as TLS and CFRG are currently doing,
but to still keep custom groups (of similar size) as an option, perhaps to
be added later after some further discussion about the best way to specify
custom groups.  

I understand that TLS currently has the means to support an escape valve for
custom groups, but it leaves the syntax entirely up to the peers to decide
upon. I think a more specific support for custom groups might be a more
useful escape valve, at least in the medium term.


> -----Original Message-----
> From: TLS [mailto:[e-mail]] On Behalf Of Santiago Zanella-
> Beguelin
> Sent: Thursday, May 21, 2015 10:53 AM
> To: Nikos Mavrogiannopoulos; Florian Weimer
> Cc: [e-mail]
> Subject: Re: [TLS] Another IRINA bug in TLS
> 
> Regarding validation of DHE parameters and how reasonable it is in
practice, I
> wanted to make some publicity for miTLS (http://www.mitls.org/).
> 
> A miTLS client maintains a table of known trusted parameters, including
the
> subgroup order for parameters with non-safe primes. When receiving
> unknown parameters from a server, it tests the primality of p and (p-1)/2
to
> check if p is a safe prime (and caches a positive result in the table). If
the
> modulus is prime but not safe, miTLS checks if it is in the table of
trusted
> parameters and otherwise rejects it. We distribute miTLS with a
pre-populated
> table of parameters which we tested thoroughly (and we welcome people to
> test further). Most of the time we hit an entry in the table.
> 
> I think a table lookup per key exchange is about as reasonable as it gets.
> 
> Cheers,
> --Santiago
> 
> ________________________________________
> From: Nikos Mavrogiannopoulos <[e-mail]>
> Sent: Thursday, May 21, 2015 12:51 PM
> To: Florian Weimer
> Cc: Santiago Zanella-Beguelin; [e-mail]
> Subject: Re: [TLS] Another IRINA bug in TLS
> 
> On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote:
> > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote:
> >
> > > Deprecating non-safe DH primes and having clients test primality of p
and
> (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors.
> >
> > I need something which prevents MITM attacks and can be applied as a
> > software update without configuration changes, and without extensive
> > testing because it is relatively risk-free.
> 
> Well, you assume that the so-called "safe primes" are universally used,
which is
> not really the case. Expecting all servers sending these parameters
wouldn't
> really work. In addition the check you have isn't complete, you'll also
need to
> calculate the order of the generator and verify it is sufficient. I don't
think that
> approach is close to being reasonable to be done on every connection.
> 
> > Rejecting handshakes in clients without additional measures risks that
> > (a) additional handshakes fail, leading to service outages and (b)
> > clients will fall back no encryption at all (after manual
> > intervention, or automatically in case of SMTP with STARTTLS and
> > opportunistic encryption).
> 
> The way I tackled the issue in gnutls is to prioritize the ciphersuites of
the client
> in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones.
> 
> regards,
> Nikos
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls