Draft: draft-ietf-tls-tls13

Commentary: 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 : 
 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 and 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 wo n'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 . my motivation for making this variable length is n'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 do n't have something like a ticket decryption key lying around . 
 Right , but as I said , that does n't apply if you have a more sophisticated self - encryption scheme , as in the examples I indicated above 
 Ca n't you implement that scheme by putting the nonce in the ticket ? 
 I do n'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 do n'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 do n't do it elsewhere in the spec where we require uniqueness . 
 Huh ? Of course we do , e.g. : ( per record nonce ) ( 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. ) 
 makes sense , nvm then 
 alternatively we could have the client send the Hash of the NewSessionTicket message back to the server during resumption , but might be overkill . 
 OK to merge ? 
 okay to merge 
 Generally I like this , just one question inline .
Paragraph (version B):
Add a per-ticket nonce so that each ticket is associated with a
different PSK (*).
Paragraph (version A):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  This message
creates a pre-shared key (PSK) binding between the ticket value and
the resumption master secret.
Paragraph (version B):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  This message
creates a pre-shared key (PSK) binding between the ticket value and a
secret derived from the resumption master secret.
Paragraph (version B):
A unique per-ticket value.
Paragraph (version B):
Because the ticket_nonce value is distinct for each NewSessionTicket
message, a different PSK will be derived for each ticket.