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

[Dave Garrett <[e-mail]>]

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


On Monday, April 25, 2016 11:17:45 am Sean Turner wrote:
> 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.