Re: [TLS] SNI with early data

[Matt Caswell <[e-mail]>]

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.


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

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

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