Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension
On 4/25/16, 8:27 AM, "Russ Housley" wrote: > >On Apr 25, 2016, at 11:19 AM, Paul Wouters wrote: > >> On Mon, 25 Apr 2016, Sean Turner wrote: >> >>> draft-shore-tls-dnssec-chain-extension was originally discussed at >>>IETF 93 [0], and the authors have been biding their time while the WG >>>thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], >>>but this time the chairs took a sense of the room about whether the WG >>>was in favor of adopting the draft. According to the minutes, there >>>were ³crickets² against and ³lots of noise² for adoption. But, we need >>>to take it to the list so please indicate whether you: >>> >>> - Support adoption and are willing to review/comment on the draft by >>>201600429. Note that the extensions is pretty straight forward, but >>>the chairs still need people to comment on the draft as we¹re >>>processing it down the path. >> >> I support and will review the document. I think it is a great idea that >> will help deploying DNSSEC and TLSA for browsers. > >+1 +1 =JeffH ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
On Tuesday, April 26, 2016 11:20:40 am Hannes Tschofenig wrote: > 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? (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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Review of draft-guballa-tls-terminology-03
I recently reviewed draft-guballa-tls-terminology-03. Comments below. OVERALL I'm sympathetic to concerns that TLS terminology may not be as precise as one would like, but IMO this document doesn't make things significantly clearer and in some cases makes it worse. Specifically: - (D)TLS is intentionally defined without any tight binding to the underlying transport. However, this document tries to tie it to IP semantics, which is not helpful and doesn't match existing practice. - This document introduces a number of terms that don't exist in the (D)TLS documents (e.g., "Transient (D)TLS session"). This is just going to cause confusion. In general, I don't think that having a second document that acts as a glossary for (D)TLS but isn't part of the main documents is going to help much. If the authors feel like the terminology in TLS is imprecise, it would be more helpful to suggest changes to TLS 1.3 (e.g., via PRs). DETAILED COMENTS S 3.1.1. There's no restriction on TLS that a given endpoint is attached to one IP address, and in fact, it's common to run DTLS in multihomed configs (e.g., DTLS over ICE). S 3.2.1. Again, (D)TLS isn't bound to the port or IP. S 3.2.2. This whole notion of semi-permanent versus transient isn't helpful, especially in the face of tickets. S 3.2.2. This is just a new invented term. Please don't S 3.3.1. Destruction point doesn't seem useful since in many cases it's "unknown" since it's in the future S 3.3.4. In DTLS you can respond to a ClientHello with a HelloVerifyRequest as well. S 3.4.4. "message sequence" seems invented. S 3.4.7. I don't think it's helpful to import ITU notions of connection state here, especially in the face of stuff like false start. S 3.4.12. Copying the session state here doesn't seem that useful, especially splitting it into two states. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
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 On 04/25/2016 05:17 PM, 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: > > - 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 > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
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.) On 26 April 2016 at 05:31, Andrei Popov wrote: > I support adoption of this draft. No reason to limit ECDHE_PSK to CBC. > > Cheers, > > Andrei > > -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner > Sent: Monday, April 25, 2016 8:22 AM > To: tls > Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead > > sigh and here as well - they should have been 20160510. > > spt > >> On Apr 25, 2016, at 08:17, 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: >> >> - 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 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
