Original text:
(*) indicates changes to the wire protocol which may require implementations to update.  draft-20 Add "post_handshake_auth" extension to negotiate post-handshake At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message <del> creates a pre-shared key (PSK) binding between the ticket value and the resumption master secret. </del>  The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello by the client.  The server MUST generate a fresh value for each ticket it sends.  The value of the ticket to be used as the PSK identity.  The ticket itself is an opaque label.  It MAY either be a database lookup key or a self-encrypted and self-authenticated value. NOT depend on being able to send large quantities of padding in early data records.  Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most Hash.length zero bytes.  Concretely, for the present version of TLS 1.3, secrets are added in the following order: <del> PSK (a pre-shared key established externally or a </del>  resumption_master_secret value from a previous connection) (EC)DHE shared secret (ecdhe-shared-secret-calculation)

Reviewer comments:
ticket is associated with a different PSK. This provides somewhat increased security in cases where you have multiple PSKs for the same connection and one PSK is compromised. The motivation here is that in cases where the server maintains a session database rather than self-encrypted tickets, the server might delete tickets as they are used,. This change provides FS for connections which have been used, even if there are other outstanding tickets in the session cache associated with the same original connection.
Big +1 to this change as we are tentatively planning to use a session-cache-like approach for resumption and this will make it possible for us to use multiple tickets, or post-auth tickets, to the same client. As-is this is not quite possible.
Is the new ticketnonce field supposed to be somehow wired to that new hkdf-expand-label call? Right now, it seems like all the PSKs produced on the same connection will be the same. The context of that call is specified to be empty, but based on surrounding text, I guess the context should be ticketnonce?
Good catch, yeah...
It might be preferable to use Hash(NewSessionTicket) in HKDF-Expand-Label rather than ticketnonce, directly, thus binding the PSK to the whole ticket. (HKDF-Expand-Label does say it wants a hash value, anyway) Also, how big of a nonce do we really need? Up to 255 bytes feels like over-generalization. If we just made it a type "Random" (same as hellos), then its 32 bytes, plus the 4 from ticketage_add (if a message hash is used), should be enough entropy to ensure uniqueness if all generated properly. It'd also be simpler to specify "32 bytes generated by a secure random number generator" yet again rather than just say it needs a unique value and leave the generation up to the implementation to figure out.
Alternative design: add an extra derive step to the generation of the PSK that takes the PSK ID as input. A server that splits their cache can perform this step as soon as they issue the PSK. So can the client if they want to. Then there is no extra nonce on the wire (the PSK ID is the nonce). That is, for resumption, change: to:
NAME NAME interesting suggestion, but kind of limiting in that it makes it impossible to implement any kind of self-encryption scheme at all (though it works fine with identities which are just lookup keys) Consider the case where instead of a session cache, the server wants to self-encrypt using a puncturable encryption scheme (see URL and URL for background) to encrypt each ticket. With the construction I propose you would do: PSKi = HKDF-Expand(RMS, nonce) ticketi = Encrypt(Kpub, PSKi) However, in the construction you propose, this won't work because it creates a circular dependency between PSKi and ticket_i. So, I think if we want to do this, it would be more flexible to have an extra nonce. NAME my motivation for making this variable length isn't to allow the nonce to be extra large but rather to allow it to be small. It seems unlikely that one would want to produce more than 2^32 tickets and so either 4 byte counter or 8 randomly-generated bytes should be plenty, especially given that the impact of collision is just a reduction of PFS to the current state.
My thought was that in a self-encrypting scheme you would save the resumption master on the principle that the ticket decryption key is your point of exposure. It only makes sense to separate keys if you don't have something like a ticket decryption key lying around.
Right, but as I said, that doesn't apply if you have a more sophisticated self-encryption scheme, as in the examples I indicated above
Can't you implement that scheme by putting the nonce in the ticket?
I don't think so, no, because the problem is the dependency of the key on its own encryption
Oh, I see now. Those schemes could work, but unless the client is involved in the process at least to the extent that a key is separated at the client, the self-encrypted ticket would have to contain the RMS, not the i-th derived PSK. At that point any ticket is a threat to any other (the basic model we have today). I'm not thrilled by those puncturable encryption papers. Storage is cheap, especially for keys. It's globally consistent synchronization that hurts. If it were me, I'd worry less about the storage problem and more about the synchronization one. I guess that the assertion is that globally consistent state for a single user's set of MTAs is manageable.
Right, that's why we would need the nonce.
I think some sort of text stating some of the possible methods to handle the nonce is warranted, rather than leaving its generation completely unspecified. Maybe have a paragraph just describing a recommended way to set up a simple session database? Should this be discussed further on-list?
We'll certainly need to discuss on the list before merging this. I'll send something relatively soon. That said, I don't believe that the changes you propose would improve the specification. It's not our job to tell people how to generate unique values and we don't do it elsewhere in the spec where we require uniqueness.
Huh? Of course we do, e.g.: URL (per record nonce) URL (says e.g. randomly generate) Also, I'm not suggesting a hard requirement; just some sort of starting point recommendation(s).
Neither of these are solely uniqueness requirements. The first of these is a requirement for interoperability. The second is an example where it's not uniqueness that matters (in fact, it used to just say unique) and now it is specifically intended to be unpredictable, which is why we mandate it. You'll note that this is a recent change made after I realized that it was a partial security condition. Prior to this it just required uniqueness.
would it be stronger to use the entire NewSessionTicket message as the context for the PSK HDKF instead of just the nonce? This would bind any extensions as well to the resumption PSK
The HKDF output is supposed to be included in the encrypted ticket, see (e.g.) URL
NAME makes sense, nvm then
NAME alternatively we could have the client send the Hash of the NewSessionTicket message back to the server during resumption, but might be overkill.
NAME NAME OK to merge?
NAME okay to merge
Generally I like this, just one question inline.

Revised text:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-21 Add a per-ticket nonce so that each ticket is associated with a different PSK (*). </ins> draft-20 Add "post_handshake_auth" extension to negotiate post-handshake At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message  <ins> creates a pre-shared key (PSK) binding between the ticket value and a secret derived from the resumption master secret. </ins> The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello by the client.  The server MUST generate a fresh value for each ticket it sends. <ins> A unique per-ticket value. </ins> The value of the ticket to be used as the PSK identity.  The ticket itself is an opaque label.  It MAY either be a database lookup key or a self-encrypted and self-authenticated value. NOT depend on being able to send large quantities of padding in early data records. <ins> The PSK associated with the ticket is computed as: Because the ticket_nonce value is distinct for each NewSessionTicket message, a different PSK will be derived for each ticket. </ins> Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most Hash.length zero bytes.  Concretely, for the present version of TLS 1.3, secrets are added in the following order:  <ins> PSK (a pre-shared key established externally or derived from the </ins> resumption_master_secret value from a previous connection) (EC)DHE shared secret (ecdhe-shared-secret-calculation)