Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread David Benjamin
On Sun, Mar 12, 2017 at 8:09 PM Martin Thomson wrote: > On 13 March 2017 at 10:55, Brian Smith wrote: > >> So, I'd prefer to bring session IDs back, and > >> to arrange things so that they're always server-generated. > > > > Even in earlier

Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Eric Rescorla
I more or less concur with Brian and Martin. I do think it would be worthwhile for someone to document a ticket construction that's more modern than the one in RFC 5705, but I don't think implementations should be required to implement any particular format. -Ekr On Sun, Mar 12, 2017 at 4:55

Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Martin Thomson
On 13 March 2017 at 10:55, Brian Smith wrote: >> So, I'd prefer to bring session IDs back, and >> to arrange things so that they're always server-generated. > > Even in earlier versions, session IDs were not required with > resumption using tickets. The server sends an empty

Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Brian Smith
Ivan Ristic wrote: > - The opaque nature of this field also makes connection auditing more > difficult. This is intentional. > For example, I'd like to know if session tickets are used to > resume for a particular connection. Perhaps more importantly, it would be > useful

Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Viktor Dukhovni
> On Mar 12, 2017, at 7:23 PM, Ivan Ristic wrote: > > Another example, perhaps relevant: load balancers can often be configured to > use sticky sessions based on TLS session IDs. It's a useful feature given > that web servers typically don't have a good story for

Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Ivan Ristic
On Sun, Mar 12, 2017 at 3:44 PM, Martin Thomson wrote: > On 13 March 2017 at 09:23, Ivan Ristic wrote: > > - Finally, I feel that the effective removal of (visible) session IDs is > a > > regression. Being able to track sessions and resumption is

Re: [TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Martin Thomson
On 13 March 2017 at 09:23, Ivan Ristic wrote: > - Finally, I feel that the effective removal of (visible) session IDs is a > regression. Being able to track sessions and resumption is useful to > understand traffic patterns. So, I'd prefer to bring session IDs back, and >

[TLS] Comments on the session ticket format in TLS 1.3

2017-03-12 Thread Ivan Ristic
The "ticket" field in NewSessionTicket is opaque and can hold an identifier or an actual encrypted ticket. I think this is problematic, for a couple of reasons: - Field and meaning overloading/reuse is a bad practice in general and leads to programming errors. I feel that protocol design should