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

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 PM, Brian Smith <brian@briansmith.org> wrote:

> Ivan Ristic <ivan.ristic@gmail.com> 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 to identify specific ticket keys (to track their usage, rotation,
> > etc), age, encryption algorithm, and their strength.
>
> The server knows this information. if it wants you to know it, then it
> can share it with you. If it doesn't, then you shouldn't be able to
> know it, ideally.
>
> > - 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.
>
> This is an attack on the client and server, which the protocol ideally
> should prevent. In fact, I know at least one implementation is doing
> extra work specifically to frustrate this kind of attack. Also the
> charter says "Develop a mode that encrypts as much of the handshake as
> is possible to reduce the amount of observable data to both passive
> and active attackers."
>
> > 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 session ID and the
> client may (should, IMO) send an empty session ID in the resumption
> hello.
>
> > I know these are not big problems (especially given the improvements
> made to
> > session tickets), but whatever is specified now will be used for a very
> long
> > time, and it would be a shame to leave these around.
>
> This I agree with, except I think it's worth spending extra effort to
> standardize the methods for preventing the thing you are asking for.
>
> BTW, I understand you are asking for this for diagnostic reasons, not
> for malicious reasons.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>