Re: [TLS] supported_versions question

On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote: > On 31/10/16 23:53, Dave Garrett wrote: > >> I came up with some alternative wording that I think captures the > >> discussion: > >> > >> https://github.com/tlswg/tls13-spec/pull/748 > > > > I see no reason to require servers to validate

Re: [TLS] supported_versions question

On 31/10/16 23:53, Dave Garrett wrote: >> I came up with some alternative wording that I think captures the discussion: >> >> https://github.com/tlswg/tls13-spec/pull/748 > > I see no reason to require servers to validate the legacy version value. > That's just excess complexity. If the extension

Re: [TLS] supported_versions question

On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote: > On 31 October 2016 at 23:13, David Benjamin wrote: > > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote: > >> > >> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: > >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara

Re: [TLS] supported_versions question

On 31 October 2016 at 23:35, Eric Rescorla wrote: > Our current implementation also processes the extension unconditionally. > > I'm not convinced that this represents an improvement, both for the reason > that Kurt > indicates and just in terms of simplicity of story. The current design is > simp

Re: [TLS] supported_versions question

Our current implementation also processes the extension unconditionally. I'm not convinced that this represents an improvement, both for the reason that Kurt indicates and just in terms of simplicity of story. The current design is simply "if supported_versions is present, then use it", whereas tr

Re: [TLS] supported_versions question

On 31 October 2016 at 23:13, David Benjamin wrote: > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote: >> >> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara >> > >> > wrote: >> > >> > > On Mon, Oct 31, 2016 at 06:43:52PM +

Re: [TLS] supported_versions question

On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote: On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara > wrote: > > > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote: > > > A few supported_versions questions: > > > > > >

Re: [TLS] supported_versions question

On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara > wrote: > > > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote: > > > A few supported_versions questions: > > > > > > 1) What should a server do if supported_versions is

Re: [TLS] supported_versions question

On Mon, Oct 31, 2016 at 09:30:10PM +0200, Ilari Liusvaara wrote: > On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: > > > > We could say the versions extension only applies to 1.2 and up. I.e. don't > > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0 > > wh

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara wrote: > On Mon, Oct 31, 2016 at 09:29:19PM +, Nick Sullivan wrote: > > > < > https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00> > > draft-sullivan-tls-exported-authenticator-00> > > < > htt

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

On Mon, Oct 31, 2016 at 09:29:19PM +, Nick Sullivan wrote: > > draft-sullivan-tls-exported-authenticator-00> > >

[TLS] draft-sullivan-tls-exported-authenticator-00

draft-sullivan-tls-exported-authenticator-00> I just posted a new Internet-Draft called "Exported Authenticators in TL

Re: [TLS] Comments on draft-ietf-tls-tls13-18

Watson, Thanks for your comments! On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd wrote: > Hello, > > Looking at the history of TLS implementation attacks we see that many > result from the standard not strictly enough prescribing behavior, > particularly of the state machine. This draft does not

Re: [TLS] supported_versions question

David Benjamin wrote: > Ilari Liusvaara wrote: > >> The case where legacy_version < TLS1.2 IIRC isn't specified, but >> ignoring legacy_version is reasonable in this case too. >> > I imagine that there will be three common implementations for the case where legacy_version < 1.2 and supported_ver

Re: [TLS] supported_versions question

I think for question 1, it should ignore legacy_version, and select a version from supported_versions, because if a client only supports TLS 1.1 and TLS 1.3, in order to connect to pre-TLS1.3 server, it has to set legacy_version to TLS 1.1. I have no idea about questions 2 or 3. Best, Xia

Re: [TLS] supported_versions question

On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: > > We could say the versions extension only applies to 1.2 and up. I.e. don't > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0 > when they see them in the version list. That keeps the protocol deployable >

Re: [TLS] Comments on draft-ietf-tls-tls13-18

On Mon, Oct 31, 2016 at 11:41:46AM -0700, Watson Ladd wrote: > ECDSA cannot be used with x25519 or x448, but the draft seems to > require support in TLS 1.2 for this as a consequence of its > description of the fallback mode. The mandated use of uncompressed > points invites easy wrong-curve attac

Re: [TLS] supported_versions question

On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote: > A few supported_versions questions: > > 1) What should a server do if supported_versions is received but > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just > ignore legacy_version? If legacy_version > TLS1.2, the spe

[TLS] supported_versions question

A few supported_versions questions: 1) What should a server do if supported_versions is received but ClientHello.legacy_version != TLS1.2? Fail the handshake, or just ignore legacy_version? 2) What should a server do if supported_versions is received, ClientHello.legacy_version == TLS1.2, but sup

[TLS] Comments on draft-ietf-tls-tls13-18

Hello, Looking at the history of TLS implementation attacks we see that many result from the standard not strictly enough prescribing behavior, particularly of the state machine. This draft does not actually fix this problem, but continues to present example flows without explicitly requiring them

Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-00.txt

Hi, Thank you for the draft. As said, I would love to have this kind of document. In TLS 1.3, multiples steps are required to derive the AEAD secrets. Without a step-by-step example, implementors need to (i.e. I had to) struggle to figure out what went wrong. I also believe that the document sh

[TLS] draft-fossati-tls-iot-optimizations-00, 4.2, hash chain

Dear Authors, draft-fossati-tls-iot-optimizations-00 mentions in 4.2, page 5, a hash chain (Lampert, "Password Authentication with Insecure Communication"). Would it be possible, to get more details about that approach? In my opinion, DTLS needs a connection id, the record is usually secured b

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

The concern here is that people won’t review it until the end and that is definitely not what we want. I’d really like get the most out of our f2f meeting in Seoul so pretty please people review it before Seoul. spt > On Oct 27, 2016, at 07:07, Salz, Rich wrote: > > So isn't it really a WGLC

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt

Yoav thanks for continuing to push this. We’ll update the status slides once we kick off the next steps. spt > On Oct 29, 2016, at 16:04, Yoav Nir wrote: > > Hi. > > This is mostly a maintenance version. I’ve updated references and removed > some TBDs for ideas that were never pursued. > >