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

[Hubert Kario <[e-mail]>]

On Monday 01 June 2015 16:02:24 Tony Arcieri wrote:
> Alternative suggestion: DHE diediedie
> 
> Is there really a compelling reason to keep it around? I expect the
> response is going to be "What if there's some catastrophic failure of ECC?"
> but if that really happens, can't we just temporarily forego forward
> secrecy rather than further complecting TLS with a backup we probably won't
> need?

as it was pointed out many times: adding support for this extension and groups 
to implementations that already support FF DHE is rather trivial, adding 
support for ECC is complex (both because of compexity of ECC and because it's 
a completely new set of algorithms)

This allows us to move away from defaulting to 1024bit or 2048bit on server 
side in fear of breaking, for example, Java based clients

> On Mon, Jun 1, 2015 at 3:50 PM, <[e-mail]> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> >  This draft is a work item of the Transport Layer Security Working Group
> > 
> > of the IETF.
> > 
> >         Title           : Negotiated Finite Field Diffie-Hellman Ephemeral
> > 
> > Parameters for TLS
> > 
> >         Author          : Daniel Kahn Gillmor
> >         Filename        : draft-ietf-tls-negotiated-ff-dhe-10.txt
> >         Pages           : 26
> >         Date            : 2015-06-01
> > 
> > Abstract:
> >    Traditional finite-field-based Diffie-Hellman (DH) key exchange
> >    during the TLS handshake suffers from a number of security,
> >    interoperability, and efficiency shortcomings.  These shortcomings
> >    arise from lack of clarity about which DH group parameters TLS
> >    servers should offer and clients should accept.  This document offers
> >    a solution to these shortcomings for compatible peers by using a
> >    section of the TLS "EC Named Curve Registry" to establish common
> >    finite-field DH parameters with known structure and a mechanism for
> >    peers to negotiate support for these groups.
> >    
> >    This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2
> >    [RFC5246], as well as the TLS ECC extensions [RFC4492].
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
> > 
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-10
> > 
> > 
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic