Re: [TLS] SNI with early data

[Benjamin Kaduk <[e-mail]>]

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

More inline.

On 07/21/2017 05:14 AM, Matt Caswell wrote:
> On 20/07/17 18:10, Benjamin Kaduk wrote:
>> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>>> 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
>> 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
>>
>>> 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
>> 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.
> Interesting because I assumed the intention was the opposite. I'm not
> 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?

>
>>  So, since the previous list is a superset, there is no problem
>> caused by this text not applying to external PSKs.
> 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

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.

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

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.

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

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

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

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

>> For tickets, the requirement that SNI must match the original connection
>> 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