Subject: [TLS] SNI with early data

From: Matt Caswell <[email-masked]>
Date: Thu, 20 Jul 2017 10:51:06 +0100

I note in draft-21 the following text:

   When clients use a PSK obtained externally to send early data, then
   the following additional information MUST be provisioned to both
   parties:

   -  The TLS version number for use with this PSK

   -  The cipher suite for use with this PSK

   -  The Application-Layer Protocol Negotiation (ALPN) protocol
      [RFC7301], if any is to be used

   -  The Server Name Indication (SNI), if any is to be used

Later it says this:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are consistent with those negotiated in the
   connection during which the ticket was established.

   -  The TLS version number and cipher suite.

   -  The selected ALPN [RFC7301] protocol, if any.

The language about "during which the ticket was established" seems to
suggest that the following checks do not apply to an external PSK -
which I don't think is intended. Additionally there does not seem to
be a requirement on the server to check that the SNI is consistent.
So, there is a mandatory requirement for an external PSK to specify
the SNI, but no requirement on the server to check that it is actually
correct. Is this discrepancy intentional?

Matt

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 20 Jul 2017 21:27:18 +0900 (JST)

Hi Matt,

You might be also interested in this issue:

https://github.com/tlswg/tls13-spec/issues/1040

--Kazu

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Jul 2017 12:10:52 -0500

>    -  The Server Name Indication (SNI), if any is to be used

These are in addition to the hash algorithm provisioned with the
external psk that is needed for 1-RTT operation, as mentioned somewhat
in passing in section 4.2.10

> which I don't think is intended. Additionally there does not seem to

These values are a subset of those listed above.  I believe this block
of text only applies to NST-provisioned PSKs being used for early data,
as the previous text applies to external PSKs being used for early
data.  So, since the previous list is a superset, there is no problem
caused by this text not applying to external PSKs.

> correct. Is this discrepancy intentional?

I'm not sure I fully understand what you are saying.
The text says that (for external PSKs) the SNI must be provisioned to
both parties, which to me implies that the server must only use the
given PSK for early data with the specified SNI.  (That is, that the
server has to check.)

For tickets, the requirement that SNI must match the original connection
is mentioned in section 4.6.1 (NewSessionTicket).

In short ... I don't see any problems here.  Do you still see a problem?

-Ben

---

From: Matt Caswell <[email-masked]>
Date: Fri, 21 Jul 2017 11:14:38 +0100

On 20/07/17 18:10, Benjamin Kaduk wrote:
> data.

Interesting because I assumed the intention was the opposite. I'm not
sure why this restriction should only apply to NST-provisioned PSKs.

>  So, since the previous list is a superset, there is no problem

The earlier text is about what needs to be *provisioned* to both
parties. This text is about what MUST be verified on the server. I
think these are two subtly different things. I see no reason to
exclude SNI from requiring to be verified, nor do I see a reason to
restrict it to NST PSKs only. Either you MUST do it for both types of
PSK or you don't need to do it at all. What is the benefit of
complicating things by providing a partial list that MUST be verified
for one type of PSK only?

If this block of text is about NST PSKs only then the implication is
that a server MAY tolerate discrepancies in ALPN for external PSK. At
least that is the way I read it (although I don't think that was the
intention).

> given PSK for early data with the specified SNI.  (That is, that the

It does not imply that to me. It says it has to be provisioned. That
fact that NST PSK MUST verify, implies to me that non-NST PSKs may
tolerate discrepancies.

> is mentioned in section 4.6.1 (NewSessionTicket).

Again...why only for NST PSKs?

> In short ... I don't see any problems here.  Do you still see a problem?

Yes - given that we have different interpretations of the same text I
still see a problem. I think it should be a lot more explicit, and
remove the discrepancies between NST PSKs and external PSKs.

There is another example of this, earlier on in section 4.2.9:

"The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, etc.) are the same as those which were negotiated in the
connection which established the PSK."

This implicitly seems to only apply to NST PSKs. Why not external PSKs too?

Matt

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Jul 2017 12:46:45 -0500

I put some proposed tidying in
https://github.com/tlswg/tls13-spec/pull/1061 .

More inline.

> sure why this restriction should only apply to NST-provisioned PSKs.

Because a similar (slightly stronger) restriction already applies to
external PSKs, but is elsewhere in the document?

> exclude SNI from requiring to be verified, nor do I see a reason to

SNI must be verified in order to use the ticket for 1-RTT, which is a
prerequisite for using it for 0-RTT.  That's just covered elsewhere in
the document, and the editor apparently didn't see a need to repeat the
requirement here.

> for one type of PSK only?

Yes, you MUST do it for both types.  It's just (prior to my pull
request) specified in different parts of the spec, due to how it evolved.

Perhaps this requires my understanding of what it means to "provision a
PSK with associated values", namely, that the given PSK is only defined
for use with those values, and (e.g.) a server that negotiates the use
of that PSK with different value(s) is in violation of the spec.  Maybe
"provisioning a PSK with associated values" can be interpreted
differently, though, but I'm still unclear on what exactly such an
alternate interpretation would be.

> least that is the way I read it (although I don't think that was the

[I'd just be repeating myself if I added something here.]

> fact that NST PSK MUST verify, implies to me that non-NST PSKs may

So ... what does it mean to have it provisioned and then not do anything
with it?  In such an interpretation, the text about needing to provision
those values along with the PSK has no practical effect, making it "dead
code" that should not have been in the spec in the first place.  An
interpretation where that text is not "dead code" seems much more plausible.

-Ben