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

So I think that the problem could be reduced in complexity.  A little
at least.  The obvious consequence of changing SNI is that you end up
somewhere different than last time.  But we can still ensure that the
connection is to the same peer.

If the server remembered which certificate it used, and insisted that
THAT remain constant, then you could take a different SNI from - for
example - a subjectAltName.  Provided that the routing works out, you
might still get the same certificate.

I mean, the point of SNI is to route to the right configuration.
Changing name messes with resumption in that you want to make sure
that you end up in a place that has the resumption secret.  But if you
end up at the wrong server, you either fail to resume, or fail to
connect on the normal terms of the protocol.

The only thing that could screw this all up is if we end up in a
situation where one or other peer is confused about either its own
identity, the identity of its peer, or the identity (-ies) that it
believes it peer has for itself.  However, with certificate stability
rather than name stability I don't think we are worse off than with -
say - a wildcard cert.

I agree that the add-a-name stuff makes this harder.  A co-tenanted
server with resumption keys across a bunch of names risks confusing
itself if it allows resumption across certificates, depending on how
much state it carries from the old session.  In doing add-a-name, then
we need to be careful about that, but that's a problem for those of us
who want to do add-a-name.

On 21 October 2016 at 12:06, Eric Rescorla <ekr@rtfm.com> wrote:
> Yeah, it does seem a bit complicated.... :)
>
> -Ekr
>
>
> On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
>>
>> Perhaps it’s OK to resume a session with a different SNI if in this
>> session the server has proved an identity that matches the new SNI.
>>
>> In order to enforce this, the server would have to cache (or save in the
>> ticket) a list of identities it presented in each resumable session…
>>
>>
>>
>> From: Eric Rescorla [mailto:ekr@rtfm.com]
>> Sent: Thursday, October 20, 2016 5:47 PM
>> To: Andrei Popov <Andrei.Popov@microsoft.com>
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] SNI and Resumption/0-RTT
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <Andrei.Popov@microsoft.com>
>> wrote:
>>
>> Ø  With that said, it does seem like there might be situations where it
>>
>> Ø  would be useful to allow resumption/0-RTT with different SNIs.
>>
>> What are some example situations where resumption with a different SNI is
>> useful
>>
>>
>>
>> A system where you have a bunch of co-tenanted names and you'd like to get
>> 0-RTT on
>>
>> SNI A after negotiating with SNI B. Basically the same conceptual
>> situation as Mike Bishops
>>
>> add-a-server-cert draft.
>>
>>
>>
>> With that said, I'm more than happy to stuff this in the "TODO-for-later"
>> list.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
>> Sent: Thursday, October 20, 2016 5:34 PM
>> To: tls@ietf.org
>> Subject: [TLS] SNI and Resumption/0-RTT
>>
>>
>>
>> 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].
>>
>>
>>
>> Following the discussion in
>>
>> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
>>
>> to the draft clarifying that the RFC 6066 rule still applies [1]
>>
>>
>>
>> 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.
>>
>>
>>
>> Comments?
>>
>> -Ekr
>>
>>
>>
>>
>>
>> [0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
>>
>> [1]
>> https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
>>
>> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>>
>>
>>
>>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>