On Fri, Mar 06, 2020 at 07:24:01PM -0800, Benjamin Kaduk wrote:
> > > It seems like this would avoid the trap of alternating full and resumption
> > > handshakes that was discussed downthread for the case where client
> > > supports
> > > reuse but server does not.
> >
> > Yes, there is some wiggle-room here. What's your sense of the best
> > way forward?
>
> So far as I know, either version will meet the technical needs, so it's to
> large extent a matter of style and "philosophical consistency with the
> rest of the protocol". My personal thoughts are that "make zero mean zero"
> makes a lot of sense, and there doesn't seem to be much burden from the
> "return whether the server supports reuse" part of things, so if I held the
> pen that's what I'd go with. But I will take whichever version the WG
> sends to me for publication.
The main reason I was reluctant to rely on the echoed extension from the
server is that it changes the data-type of the client's ticket cache, it
is no longer just an array of tickets, there now needs to be additional
associated metadata. This is likely not a major burden, but a small
potential hurdle.
If we do get to specify reuse, then ultimately either choice can work,
with the new alternative being that an echoed extension supporting
reuse (in whatever form that takes) is required for the client to
attempt reuse. Perhaps that's the cleaner option. I failed to
consider making the echoed extension (optional in the original
text) mandatory in the reuse case. Thanks for noticing.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
