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
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
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
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
> 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
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
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
>
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