RE: Requiring per application data in session ticket seems wrong

[Mike Bishop <[e-mail]>]

As noted on the issue, it's worth remembering that RFC 8446 specifically talks about 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 the same as those associated with the
   selected PSK:

   -  The TLS version number

   -  The selected cipher suite

   -  The selected ALPN [RFC7301] protocol, if any

   These requirements are a superset of those needed to perform a 1-RTT
   handshake using the PSK in question.  For externally established
   PSKs, the associated values are those provisioned along with the key.
   For PSKs established via a NewSessionTicket message, the associated
   values are those negotiated in the connection during which the ticket
   was established.

ALPN matching is a requirement for early data with TLS 1.3.  Embedded application data is a requirement for Early Data with QUIC, and it relies on this existing requirement.  If some future version of TLS doesn't have this requirement, QUIC will need to decide how to cope with that.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Benjamin Kaduk
Sent: Friday, September 13, 2019 12:43 PM
To: Christian Huitema <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: Requiring per application data in session ticket seems wrong

On Thu, Sep 12, 2019 at 09:52:01PM -0700, Christian Huitema wrote:
> I am busy implementing draft-23 in picoquic, and I found out the new 
> section 5.4. of the transport draft, "Required Operations on 
> Connections".  It is fine, except for the requirements that servers 
> are able to encode application specific settings in the session resume 
> tickets. This makes the ticket specific to the combination of SNI + 
> ALPN, instead of just SNI as implied by RFC 8446. Seems like a bad idea.
> More discussion in https://github.com/quicwg/base-drafts/issues/3028.

It's not clear to me that this specifically makes the ticket tied to the ALPN, but rather that a given ticket (still tied to SNI) may or may not have some additional information that allows for additional functionality when used with a specific ALPN.  A ticket with that additional information could well be used with a different ALPN and the same SNI (though the logistics of getting additional information in place that would allow a single ticket to get enhanced functionality with more than one ALPN could be challenging.  In this case, if you don't have that additional information, you can't use early data, for example.

-Ben