[TLS] Zero length fragments and fragmented Alert messages

Current draft states: Alert messages ({{alert-protocol}}) MUST NOT be fragmented across records. and Implementations MUST NOT send zero-length fragments of Handshake or Alert types, even if those fragments contain padding. But I don't see what is the expected behaviour of the side

Re: [TLS] Zero length fragments and fragmented Alert messages

" decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. " I suppose you could argue that: " This alert is used for errors where the message does not conform to the formal protocol syntax. "

Re: [TLS] New review through the TLS 1.3 Editor's Copy

On Monday, 17 October 2016 21:10:30 CEST Ilari Liusvaara wrote: > > ## Decoding Errors > > > > TLS defines two generic alerts (see {{alert-protocol}}) to use upon > > failure to parse a message. Peers which receive a message which cannot be > > parsed according to the syntax (e.g., have a length

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

I think there might be consensus to ask for code points but not early. This draft can’t really proceed any faster than the TLS1.3 and 4492bis drafts. spt > On Oct 17, 2016, at 12:03, Daniel Migault wrote: > > Hi, > > I am not clear what the consensus is for the

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

On Tue, Oct 18, 2016 at 04:22:59PM +, Xiaoyin Liu wrote: > Why does this draft normatively depend on TLS 1.3, even if the > cipher suites defined in this draft use the old syntax, which > TLS 1.3 no longer uses? I don't see any reason why it would normatively depend. If it claims to be so,

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

Why does this draft normatively depend on TLS 1.3, even if the cipher suites defined in this draft use the old syntax, which TLS 1.3 no longer uses? Best, Xiaoyin From: Sean Turner Sent: Tuesday, October 18, 2016 9:19 AM To: Daniel

Re: [TLS] Industry Concerns about TLS 1.3

On Sat, Oct 1, 2016 at 4:23 AM, Peter Gutmann wrote: > Ryan Carboni writes: > > >I've never quite understood what TLS was supposed to be protecting > against, > >and whether or not it has done so successfully, or has the potential to > do so >

[TLS] Call for agenda items @ IETF 97

The preliminary IETF 97 agenda is out: https://datatracker.ietf.org/meeting/97/agenda.html. We’re currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. Please send in agenda requests. But, please note that TLS 1.3-related issues and WG drafts will be given a priority during the

Re: [TLS] PR#634: Registry for TLS protocol version ID

It doesn't look like we have enough consensus to adopt this proposal. Thanks, J On Sun, Oct 16, 2016 at 6:03 PM, Eric Rescorla wrote: > Chairs: Can you advise on the disposition of this? > > -Ekr > > > On Wed, Oct 12, 2016 at 6:10 PM, Martin Thomson >

Re: [TLS] New review through the TLS 1.3 Editor's Copy

I've updated the draft in response to a bunch of these comments and scheduled some for update when I enter my own review comments which are still in the "marked up document stage" > > EncryptedExtensions. > > : responses to any extensions that are not required to > > determine the cryptographic

Re: [TLS] New review through the TLS 1.3 Editor's Copy

[I trimmed a couple things that already had sub-threads spun off; leaving in others even where I don't have a comment right now] On 10/17/2016 01:10 PM, Ilari Liusvaara wrote: > >> Finally, the client and server exchange Authentication messages. TLS >> uses the same set of messages every time