Subject: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 23 Jun 2014 05:27:45 +0000

WG Members,

The chairs would like to get the sense of the WG on adopting
as a WG document:

http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02

Please make any comments in favor of or against adoption by
Friday July 4. Note: the chairs are aware that there has been
some discussion of the specific groups in this document. 
Adopting this document does not commit the WG to these 
groups as some or all of these groups may be changed prior 
to publication.

Thanks

Joe
(for the chairs)

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 23 Jun 2014 10:31:23 +0200

I favor the draft.

In sec. 3.1 however, I would rather define a new Server Key Exchange
message type, where only dh_Ys is sent (and signed). For complying
implementations, this should be a small change to implement, but it
completely eliminates ambiguous messages and signatures thereof.

We could push even further, and force the server to use the same messages
as the client: Key Exchange + Certificate Verify (to defeat cross protocol
attacks); but I understand this is a long shot for a draft which is meant
to be minimal and quick to implement.

Best,
Alfredo

On Mon, Jun 23, 2014 at 7:27 AM, Joseph Salowey (jsalowey) <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Jun 2014 14:01:48 +0200

> groups as some or all of these groups may be changed prior 

I support the adoption of this document.

---

From: Tapio Sokura <[email-masked]>
Date: Tue, 24 Jun 2014 06:12:00 +0300

Hello,

> http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02

Looks good, I support this.

A small editorial note, the middle of section 1.2 should include the
abbreviation ECDHE immediately in the sentence where it is spelled out,
for example "TLS also supports elliptic-curve-based Diffie Hellman
ephemeral (ECDHE) key exchanges, but this document does not discuss
their use."

My layman view on section 5.1 is that I don't think the server needs to
indicate it's support of named DHE groups if the negotiated ciphersuite
doesn't use them. The client should not make any conclusions about the
support of named DHE groups on the server now or in the future, if the
server chooses a non-DHE group. Consequently the client should always
include the extension on every ClientHello, if the client is willing to
use those groups.

A good thing in including a 1024 DHE group (section 5.2) in the named
group list would be that the client would not need to verify that the
group parameters are secure when using a small group. But then again a
modern server or client that comes to support this extension will with
very high probability support the stronger groups anyway, so I don't
think there is a need for weak groups in the spec. If we think of the
strengths of the groups in the draft, 112-125-150-175-192 bits, do we
even need the 2432 bit group, it's so close to a 3072 bit group?

  Tapio

---

From: Watson Ladd <[email-masked]>
Date: Mon, 23 Jun 2014 21:19:57 -0700

Dear all,

I'm very undecided about this proposal. While it does solve a security
issue in TLS, so does disabling DHE in favor of ECDH. It's likely that
this extension will not be widely deployed, and DHE without the
extension is insecure. I think we run the risk of implementations
supporting DHE, ostensibly with the extension, but in practice still
vulnerable to Triple DH. Given the performance disadvantages of DHE
compared with ECDH, I don't really see a benefit to supporting it,
given that legacy implementations will not support this extension.

Sincerely,
Watson

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 24 Jun 2014 11:24:09 +0200

> given that legacy implementations will not support this extension.

The disadvantage of what you propose is that we stick with ECDHE, and on
the first vulnerability known for the ECDHE ciphersuites we have no
alternative to fall back (note that the proposal solves a compatibility
issue of the DHE ciphersuites, it is not solely a security enhancement
as you imply - see the abstract and introduction).

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Tue, 24 Jun 2014 06:05:05 -0400 (EDT)

----- Original Message -----
> From: "Tapio Sokura" <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, 24 June, 2014 5:12:00 AM
> Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02
> 
> Hello,
> 
> If we think of the

112 bits matches the strength of 3DES, while 125 bit is basically the 128 bit
level of AES or Camellia.

Since the work factor for the server increases exponentially, I'd say that yes,
we need both 2432 bit and 3072 bit groups.

-- 
Regards,
Hubert Kario