Re: [TLS] SNI and Resumption/0-RTT

[Ilari Liusvaara <[e-mail]>]

On Thu, Oct 20, 2016 at 05:33:41PM -0700, Eric Rescorla wrote:
> We used to explicitly say that you had to check SNI for 0-RTT (but
> didn't say anything about resumption). On the principle that 0-RTT and
> resumption should be the same I removed that, but it turns out that
> the document doesn't actually have any rule at all other than the one
> we've inherited from RFC 6066, which clearly says that you can't
> resume with a different SNI [0].

If you define "resumption" as "using PSK provisioned by NST", there is
a pretty major difference between "resumption" and "0-RTT".

The symmetry arguments are between "PSKs provisioned by NST" and
"PSKs provisioned externally", not between PSKs of any kind and 0-RTT.

> With that said, it does seem like there might be situations where it
> would be useful to allow resumption/0-RTT with different SNIs. My
> intuition (partly informed by [2]) is that this is something we should
> be pretty careful about and have the server opt-in explicitly (if at
> all) but I'm willing to be wrong about that.

IIRC, Martin Rex used to argue that the rule should be "would result in
the same certificate". Of course, defining the "same certificate" is
way trickier than it initially seems (runs into the same type of
philosophical problems as "Trigger's broom")...

Maybe one interpretation would be that the server can choose a
certificate that is valid for both old and new SNI... That is at least
a consistent rule (no idea about any sort of usefulness).

Or another: The certificate that would be chosen for new SNI is
also valid for old SNI (or vice versa). These rules are subtly
different.

Or saving the list of domains for the selected certificate in
the original connection and then allowing PSK with any of those.


One thing to be very careful of: What careless server that omits the
checks can cause (the checks are relatively complex and subtle, so
getting that wrong is to be expected).


-Ilari