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

[Martin Thomson]

On 24 November 2016 at 09:46, Victor Vasiliev  wrote:
> For concreteness, I wrote a pull request that describes (2):
> 

At this point, I think that it would be more sensible to write a
separate extension draft.  There are a bunch of additional
considerations that would be easier to write down in a dedicated
document.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Victor Vasiliev]

It seems that this issue has not been so far successfully resolved, and to
the
best of my knowledge it has not been discussed during the meeting in Seoul.
 I
still believe that this is a valuable feature, and our experience with 0-RTT
handshake deployment in QUIC has indicated that it's basically required to
make
0-RTT work for YouTube videos.

So far, we have considered three options in this thread:
  (1) Retain RFC 6066 restriction on SNI,
  (2) Allow resumption for different SNI provided it was negotiated in the
  ticket,
  (3) Always allow resumption for different SNI.
In both (2) and (3), the certificate for the original ticket issuer would
have
to be valid for the new server name, of course.

I believe that (2) will result in a higher resumption success rate than (3),
since for the servers that do not support shared resumption key, (3) would
result in losing session tickets to unsuccessful resumption.

For concreteness, I wrote a pull request that describes (2):

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

Picking a message somewhat at random to reply to with some more-general
observations...

On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
> I believe that an ability to resume across different server_name values
> specified in the subjectAltName of a certificate will have a positive
> performance impact on the websites which due to various reasons have
> to fetch
> resources from different servers.  A particular use case I have in
> mind is when
> a website maintains a pool of servers, say, *.cdn.example.com
> ,
> and supplies a
> specific server directly in a resource URL.  In that case, all the servers
> already share a wildcard certificate with a secret, so they can share
> a ticket
> key too, meaning it makes sense for them to accept the ticket issued
> by another
> server in the pool.
>

I think it is useful to distinguish between this case, where
[cdn.]example.com is the owner of all the content involved, from other
co-tenanted names that have different content owners, such as from a
shared hosting service.  The wildcard cert is pretty clearly in the
"same content owner" case, but even subjectAltNames in a single cert do
not necessarily provide the same indication -- I understand that some
CDNs offer a lower-cost TLS option by means of being a SAN on a cert
that shares names with many different CDN customers.

So, even the server's configuration settings may change as a result of
SNI (e.g., a hosting provider may let customers configure settings
differently even when served from the same TLS server).

> There are potential confusion issues associated with using a ticket for a
> different server name, both with the server becoming confused and the
> client
> becoming confused.  On the server side, this requires implementations
> to know
> how to handle SNI value change.  I suggest that the servers should
> explicitly
> indicate to the client that a newly issued ticket may be used for all the
> subjectAltName values present in the server's certificate.
>

I would argue that changing SNI value on resumption or 0RTT only has a
hope of making sense in the "same content owner" case ... but the client
may not have an easy way of knowing, in the absence of an explicit
server signal as you propose.

> Clients must also account for any per-host differences before offering a
> ticket.  For instance, web browsers typically require users to pick a
> certificate for each domain they authenticate to, so resumption across
> different SNI values should obviously not happen here.  One can also
> imagine,
> say, a client which uses different cipher configuration or a different
> set of
> trust anchors for each host.  In all of those cases, it is on the
> client to not
> cross-resume, but a lot of those concerns are application-specific in
> nature,
> so I am not sure how much guidance can the TLS specification provide
> on this
> matter.
>
>

Things are getting messy enough that I'm starting to lean towards just
not doing it at all (perhaps with the carve-out for future behavior that
Chrstian wants, if we can satisfy ourselves that it won't ossify).

-Ben

> On Thu, Oct 20, 2016 at 8:33 PM, 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].
>
> 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
> 
> 

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

[Martin Rex]

Kyle Nekritz wrote:
>
> I do think this should be allowed if the client is satisfied with the
> previous identities presented. We currently allow resumption across
> domains supported by our wildcard certificate (I believe this is fairly
> common practice), and our clients take advantage of this to improve their
> resumption rate. In regards to the referenced paper, I don't think this
> is any more dangerous than the wildcard certificate itself as a full
> handshake would succeed anyway. I don't think it's entirely necessary
> for the server to opt-in to this either, if the server wants it can
> simply reject the resumption attempt.

I think it is a bad idea to look at this purely from the perspective
of whether this represents an obvious attack vector.

And there are two entirely *independent* decisions involved.

  (1) whether the TLS client proposes resumption for a session
  (i.e. client-side cache management)

  (2) whether the TLS server agrees to a proposed resumption
  or whether it performs a full handshake instead

And there are _different_ security trade-offs in these two distinct
decisions.

As I previously described my position, I'm perfectly OK with a server
performing a resumption if the full handshake would cause the server
to send/present the very same TLS server certificate as in the full
handshake that created the session that is proposed for resumption
... and that is actually the behaviour which I implemented, and
what comes out naturally if you implement TLS extension SNI support
_outside_ of the TLS stack on the server side.

However, I believe that the server agreeing to resumption with a
different SNI hostname is a use case, that with a sensible
generic TLS client, should never actually occur in practice.
Except for bugs or design flaws in the client-side session cache management
maybe.

The client does _not_ know which TLS server certificates the server has
available, and what criteria it will apply for selecting one or the other.
The existence of a wildcard certificate does not unconditionally preclude
existence of host-specific certificates for specific services that are
technically covered by the wildcard.  I really dislike seemingly
non-deterministic behaviour, and therefore try to avoid it as much
as possible in whatever I implement.

The decision to accept a particular server certificate for one specific
hostname/target does not (should not) necessarily apply to *each* other
possible servername covered/conveyed by that server certificate.

Special-casing stuff makes the behaviour also difficult to comprehend
for end-users / consumers (and implementers get it wrong more easily).
What if the server certificate is "manually" confirmed by the end-user
(for whatever reason:  it's self-signed/untrusted or from DANE rather
that PKIX) should that "acceptance" still/also transcend to all other
hostnames (why or why not)?

My client-side TLS session cache management (which I implemented above
the TLS stack), uses the target hostname as one of the session cache
lookup parameters, and I don't think it would be sensible to propose
arbitrary sessions for resumption.

The performance overhead for a full handshake per hostname is completely
negligible (and if the server operator cares, he could simply avoid
spreading content over distinct server hostnames).

What I found painful instead, is the server-side behaviour implemented
by Microsoft IIS / SChannel in the past, because when configured for
optional client certificates, the server exhibits Alzheimer towards
certificate-less clients (or at least it did so in the past),
because it would force each client without client cert through
a full renegotiation handshake after resumption for each new connection,
failing to memorize that the resumed session was created by renegotiation
where the server did ask for a client cert and the client did turn down
that request.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

> The server ought to perform a full handshake whenever the full handshake will 
> result in selection & use of a _different_ TLS server certificate than what 
> was used for the original full handshake on a session resumption.
I think this is correct, assuming a server is only able to present one cert in 
a TLS session (which is currently the case).

However, this does not mean that the SNI at resumption time has to match the 
SNI at session establishment time, because the same server cert can match 
multiple SNIs.

Also, there appears to be interest in allowing the client to request server 
auth post-handshake. If this gets supported, a server may prove multiple 
identities to a client within the same TLS session. And then perhaps the client 
should be able to resume the session with an SNI that matches any of the 
identities the server has proved in this session.

Cheers,

Andrei

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Friday, October 21, 2016 6:52 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Eric Rescorla <e...@rtfm.com>; tls@ietf.org
Subject: Re: [TLS] SNI and Resumption/0-RTT

Andrei Popov 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?

The current wording in rfc6066 may be slightly confusing about what is acutally 
important and why.

The server ought to perform a full handshake whenever the full handshake will 
result in selection & use of a _different_ TLS server certificate than what was 
used for the original full handshake on a session resumption.
This is a direct consequence of the principle of least surprise.

This is also the most backwards-compatible behaviour when upgrading the server 
from a does-not-support-SNI to a supports-SNI state/implementation.

You do *NOT* want to have session caching interfere with the server certificate 
that a client gets to see, because that would essentially result in 
not-quite-deterministic server behaviour.

Sometimes there may be bugs in client-side session caching, and clients 
proposing the wrong session for resumption, and the server doing a full 
handshake results in interoperable, deterministic and secure behaviour.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

I mentioned obfuscation as one possible solution. I know that I can make it 
work for small scale servers, e.g., up to a few hundreds registered clients. 
But if we can achieve the same privacy results with some mechanisms using 
dynamic certificates, that's fine too. My only point is, please don't forbid 
future privacy enhancement with a hard rule on SNI. Maybe something like 
"should use the same SNI, but may use different ones if client and server agree 
on an SNI privacy scheme."

-- Christian Huitema 

> On Oct 21, 2016, at 8:14 AM, Ilari Liusvaara  wrote:
> 
>> On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
>> I am a bit worried about privacy implications of the SNI. Suppose
>> that we invent an obfuscation mechanism that prevents third parties
>> to track which service corresponds to an SNI string. The SNI would
>> then be different for any connection, including resumptions. Do we
>> want to prevent that with a hard rule in the spec?
> 
> Such mechanism on TLS level would be pretty hard to do. You can't do
> any sort of static encryption or obfustication for instance (because
> that would be trivially attackable).
> 
> 
> Much more feasible to have application layer (with possibly TLS protocol
> support) way of sending new server certificates in the fly (post-
> handshake auth, but with servers).
> 
> (It seems to me that due to the roles of HTTP clients and servers, post-
> handshake server auth is a lot less scary than post-handshake client
> auth).
> 
> 
> -Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
> I am a bit worried about privacy implications of the SNI. Suppose
> that we invent an obfuscation mechanism that prevents third parties
> to track which service corresponds to an SNI string. The SNI would
> then be different for any connection, including resumptions. Do we
> want to prevent that with a hard rule in the spec?

Such mechanism on TLS level would be pretty hard to do. You can't do
any sort of static encryption or obfustication for instance (because
that would be trivially attackable).


Much more feasible to have application layer (with possibly TLS protocol
support) way of sending new server certificates in the fly (post-
handshake auth, but with servers).

(It seems to me that due to the roles of HTTP clients and servers, post-
handshake server auth is a lot less scary than post-handshake client
auth).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
> 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.

You _might_ end up somewhere different. And even with the same SNI, you
can still end up to different server in the same "group". And different
SNI names can still get you to the same actual place.

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

There are three tasks of SNI:

- Routing to the correct server. Sometimes this routing is performed by
  middleboxes (yay, middleboxes!).
- The certificate selection within the server.
- Set application instance, if the protocol can't do this in-band (but
  if it does, applications generally override this with in-band value).

And I would expect the servers to actually look at the PSKs offered and
not blindly trying to use one, so if connection is routed wrong, I would
expect fallback to the usual DH-CERT handshake.

> 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 would expect such confusion about own identity to be pretty much the
norm for HTTP servers. And those are frequently used in ways that tend
to amplify even a small errors to serious attacks.

For other types of servers, I would expect any confusion resulting in
security problems to be pretty rare.

But since HTTP is very important usecase, this impiles that the client
shouldn't attempt to use PSKs when such confusion could create security
issues.

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

You can already get such confusion with wildcard certificates, no
changes needed.. 


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

Ilari Liusvaara wrote:
> On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
>> On 21 October 2016 at 19:55, Ilari Liusvaara  
>> wrote:
>>> Of course, defining the "same certificate" is
>>> way trickier than it initially seems
>> 
>> Not if you think simplistically: same octets in EE ASN1Cert
>> in both handshakes.
> 
> Such behaviour would run into problems with certificate renewal.

Just the opposite.  You definitely want full handshake on
certificate renewal.

I don't know how common it is in TLS servers (and TLS clients) to
allow replacing of TLS certificates in "full flight".  I implemented
this in ours about 10 years ago, and I'm flushing the session cache
after loading of the new/updated cert, so that every new handshake
will result in a full handshake rather than session resume (ongoing
connections continue to use the old/previous certificate until
closed by the application).

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
> On 21 October 2016 at 19:55, Ilari Liusvaara  wrote:
> > Of course, defining the "same certificate" is
> > way trickier than it initially seems
> 
> Not if you think simplistically: same octets in EE ASN1Cert in both 
> handshakes.

Such behaviour would run into problems with certificate renewal.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

Andrei Popov 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?

The current wording in rfc6066 may be slightly confusing about what is
acutally important and why.

The server ought to perform a full handshake whenever the full handshake
will result in selection & use of a _different_ TLS server certificate
than what was used for the original full handshake on a session resumption.
This is a direct consequence of the principle of least surprise.

This is also the most backwards-compatible behaviour when upgrading the
server from a does-not-support-SNI to a supports-SNI state/implementation.

You do *NOT* want to have session caching interfere with the
server certificate that a client gets to see, because that would
essentially result in not-quite-deterministic server behaviour.

Sometimes there may be bugs in client-side session caching,
and clients proposing the wrong session for resumption, and the server
doing a full handshake results in interoperable, deterministic and
secure behaviour.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 21 October 2016 at 19:55, Ilari Liusvaara  wrote:
> Of course, defining the "same certificate" is
> way trickier than it initially seems

Not if you think simplistically: same octets in EE ASN1Cert in both handshakes.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

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:e...@rtfm.com]
Sent: Thursday, October 20, 2016 5:47 PM
To: Andrei Popov <andrei.po...@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.po...@microsoft.com<mailto:andrei.po...@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-boun...@ietf.org<mailto:tls-boun...@ietf.org>] On Behalf 
Of Eric Rescorla
Sent: Thursday, October 20, 2016 5:34 PM
To: tls@ietf.org<mailto: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

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

[Eric Rescorla]

On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov 
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-boun...@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

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

[Andrei Popov]

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

Thanks,

Andrei

From: TLS [mailto:tls-boun...@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