Draft: draft-ietf-tls-external-psk-guidance

Commentary: Related issue and discussion : 
 please let me know what you think of the suggestion above ! 
 I disagree that those analyses are out of scope since they concern the use of external PSKs , but if " out of scope " is understood to be synonymous with " we 're not going to do it , " then this change is fine . :) 
 Indeed -- " out of scope for this document " means " we 're not doing it in this document . " 
   in her review writes : What sort of precautions should they take ? Do we want to make any recommendations .   provided some recommendation on the mailing list : [ JLS ] There are going to be three different cases for external PSK identities : The identity if factory provisioned and carried in a file to the server , the identity is factory provisioned and read by the user from the device , and it is hand chosen . The first two cases can definitely be randomized . I do n’t know that having a minimum length makes any difference . This is not exactly a cryptographic property . Another thing that might be done would be analogous to the PSK importer document and apply a one way hash from the typed in value to the value that is sent over the wire so on the wire it is just a random set of bytes . 
 nit : s / his / her :-) 
 Is n't there a fourth case JLS did n't mention , namely some other out - of - band provisioning over a secure connection ? In that case , a new PSK could be provisioned after each use . ( This might seem silly , but I 've seen two separate use - cases for this . ) Alternatively , in any of those cases , is it feasible to do some sort of ratcheting ? ( This is sort of expanding on the last sentence in JLS 's paragraph . ) 
  , there is . I 'm wary about writing down any sort of recommendation here , though , as they would probably require analysis . ( In contrast to the recommendations about PSK length , for which we understand the requirements quite well , I do n't think we have a good way to reason about techniques to deal with external PSK privacy ... yet . ) 
 In that case , I 'm in favor of deleting this line : " Applications should take precautions when using external PSKs to mitigate these risks . " Mentioning precautions we do n't describe is less helpful than not mentioning them at all ( since it 's confusing ) . Even better though would be to state that such precautions are an open problem that require analysis . 
 Yep , that seems reasonable to me ! 
 - At this point I would implement the - lets roll over the PSK on each use into the case of issuing tokens and just void the PSK ( and token ) on the first usage . 
 What type of analysis are you looking for on this ? It hardly needs to have a cryptographic analysis since this is not a cryptographic property . Are you looking for some analysis that the input and output can not be correlated ? 
 Minimally , yes . 
 While it may be odd - you could ask the PSK importer document to do this and just note the privacy problem here . 
 would you mind proposing text ( preferably for this document ) ? 
 What sort of tokens are you referring to ? 
 In this case the token should be ticket . I have token on the brain because that is what we use for a similar idea in ACE . 
 do you think this issue is resolved ? 
 Yep ! 
 Excellent -- closing as is !
Paragraph (version A):
PSK privacy properties are orthogonal to security properties
described in sec-properties.  Traditionally, TLS does little to keep
PSK identity information private.  For example, an adversary learns
information about the external PSK or its identifier by virtue of it
appearing in cleartext in a ClientHello.  As a result, a passive
adversary can link two or more connections together that use the same
external PSK on the wire.  Applications should take precautions when
using external PSKs to mitigate these risks.
Paragraph (version B):
PSK privacy properties are orthogonal to security properties
described in sec-properties.  Traditionally, TLS does little to keep
PSK identity information private.  For example, an adversary learns
information about the external PSK or its identifier by virtue of it
appearing in cleartext in a ClientHello.  As a result, a passive
adversary can link two or more connections together that use the same
external PSK on the wire.  Techniques for mitigating these risks
require analysis and are out of scope for this document.