Subject: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

From: Sean Turner <[email-masked]>
Date: Mon, 25 Apr 2016 08:17:45 -0700

All,

draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are needed for TLS1.3.  We need to get these officially registered so the chairs would like to hear whether there is WG support for adopting draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you:

- Support adoption and are willing to review/comment on the draft by 201600429; the chairs still need people to review the draft to show there’s support for it as we process it down the path.

- Object to the adoption of this draft as a WG item, please respond to the list indicating why by 201600429.

Note 1: This draft will get published using the new rules we’ve been concocting on the list so the IANA considerations section will get tweaked as we settle on what words need to be included.

Note 2: The other option is to put the registrations in the TLS1.3 spec, but that would add four pages that I’m pretty sure no implementer is going to read so there seems to be little point in included the registrations in the TLS1.3 spec.  And, these cipher suites do apply to TLS1.2.

Cheers,

J&S

---

From: Sean Turner <[email-masked]>
Date: Mon, 25 Apr 2016 08:21:35 -0700

sigh and here as well - they should have been 20160510.

spt

> On Apr 25, 2016, at 08:17, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 25 Apr 2016 19:31:18 +0000

I support adoption of this draft. No reason to limit ECDHE_PSK to CBC.

Cheers,

Andrei 

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, April 25, 2016 8:22 AM
To: tls <[email-masked]>
Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

spt

> Note 2: The other option is to put the registrations in the TLS1.3 spec, but that would add four pages that I’m pretty sure no implementer is going to read so there seems to be little point in incl…

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

---

From: Dave Garrett <[email-masked]>
Date: Tue, 26 Apr 2016 05:22:05 -0400

Just to make note on-list, I support adoption of the draft. I've already cited it in the current TLS 1.3 draft as a normative reference, and thus consider it required for completion of the new version.

One objection to part of the current draft, though, which I think needs changing. It currently states that implementations have a MUST-level requirement to use no less than 255-bit curves with AES-128 and 384-bit curves with AES-256. Due to discussion on here a bit back, my current opinion is that the floor should be set to 255-bit for both. Yes, ideally you'd prefer comparable security levels, but AES-256 gives some PQ resistance and bigger ECC is just as dead there as with a smaller curve. Transitioning to stronger symmetric, over the long term, need not be held back by performance worries if some were required to use slower ECDHE, especially with some devices that may be using PSK for performance reasons.

Also, I'd much prefer this be adopted as a separate draft and not merged fully into the TLS 1.3 draft.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Apr 2016 21:22:50 +1000

Yes, adopt.  We need something approximately like this and I think
that it can proceed well ahead of TLS 1.3.  (Dave's nit seems
reasonable, but adoption lets us fix that in the working group.)

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 26 Apr 2016 16:05:47 +0200

On Mon, 2016-04-25 at 08:17 -0700, Sean Turner wrote:
> All,
> 
> draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that
> are needed for TLS1.3.  We need to get these officially registered so
> the chairs would like to hear whether there is WG support for
> adopting draft-mattsson-tls-ecdhe-psk-aead. Please let us know
> whether you:

I support this draft. However see comment below.

The text: "For the AES-128 cipher suites, the TLS Pseudorandom Function
(PRF) with SHA-256 as the hash function SHALL be used and Clients and
Servers MUST NOT negotiate curves of less than 255 bits." is very
tricky.

Implementations do not restrict ciphersuites based on curves (there is
no such notion in TLS, nor mentioned in rfc4492), and I cannot even
think how a TLS handshake implementation would look like if each
different ciphersuite has specific curve requirements.

Note that this requirement is unlike the suiteB RFC (rfc6460) that also
restricts the curves. SuiteB specifies a profile/set of parameters
which include ciphersuites, while this draft only defines ciphersuite
code points.

If a side goal of this draft is to deprecate the <255 bit elliptic
curves from TLS 1.2, or to unify security levels across ciphersuites
then I'd recommend to do that with a separate RFC rather than bundling
it into a code-point assignment RFC.

regards,
Nikos

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Apr 2016 17:20:40 +0200

My 5 cents.

For the IoT environment this ciphersuite is not very useful.

If you want the best possible performance, lowest RAM utilization and
use as little flash as possible then you go for a plain PSK ciphersuite
(without DH/ECDHE).

If you are already paying the price of the asymmetric crypto (in terms
of flash usage/CPU speed/RAM utilization then just switch to a raw
public key or a certificate based ciphersuite (since there is very
little additional overhead).

I suspect the usage is more for the we or so?

Ciao
Hannes

---

From: Dave Garrett <[email-masked]>
Date: Tue, 26 Apr 2016 15:13:00 -0400

> I suspect the usage is more for the we or so?

(assuming that was supposed to be "web")

With resumption now done through PSK in TLS 1.3, these suites will be desired for that in addition to systems that will be using PSK as their primary suite. Without them, the only FS AEAD PSK AES suites are DHE, and we'd much prefer ECDHE be available.

Dave