Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04

[Christopher Wood <[e-mail]>]

On Thu, Apr 23, 2020, at 8:10 AM, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: TLS <[e-mail]> On Behalf Of Christopher Wood
> > Sent: Tuesday, April 21, 2020 9:57 PM
> > To: [e-mail]
> > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-
> > importer-04
> >
> > Thanks for the feedback, Scott! Please see inline below.
> >
> > On Tue, Apr 21, 2020, at 6:57 AM, Hollenbeck, Scott wrote:
> > > 2. Technical comments.
> > >
> > > a. Distinct identities?  Sec. 3 states "Non-imported and imported PSKs
> > > are distinct since their identities are different on the wire."  We
> > > have two concerns about this statement.  First, the statement appears
> > > to suggest that if two EPSKs have different identities, then they must
> > > have different secret values.  But couldn't two EPSKs have the same
> > > secret value yet employ different identities for convenience?  For
> > > example, an endpoint might identify the same EPSK with a domain name
> > > in some cases and with an IP address in others.
> >
> > This seems like a reasonable editorial improvement to make. I filed:
> >
> >    https://secure-web.cisco.com/1WQM3tDUuuSkXPZ-
> > qwaA2YKrAcqlkOAsqUSqvQThf6zv7T7Gi7ofekeY-6UPrqcF1k5cW-
> > i8pc5KYZ8GDkbBhgNSydezOTkChVTOsIlACtvE0hnca9DN7D056URvddDaO54LI
> > jMM4o4hOFRlCHReLnVJ4g90Pm0foS9AAaeBQK2w1oTQNJrx9B6EqDlIvn3-
> > Sh3oF_cBDlKk0XXLyJYWRZRflbYw3Tg1Ga8HPzfUZf-
> > qJqqQquKG5sEsl_vdKIQbyIVGSYJVTTx6x-
> > viXGJXTsQ/https%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external-
> > psk-importer%2Fissues%2F31
> 
> Thanks!
> 
> > > Second, and more
> > > fundamentally, the statement assumes that a non-imported EPSK, by
> > > definition, cannot be misinterpreted as an imported PSK.  But isn't
> > > the identifier of a non-imported EPSK just an opaque string?  A
> > > non-imported EPSK identity could therefore have the same "bits on the
> > > wire" as an IPSK identity, if the client and server employ an
> > > identifier system that whose encoding happens to coincide with the
> > > ImportedIdentity structure defined in the draft.  (  Moreover, the
> > > identifier of a resumption PSK is just an opaque string
> > > -- so couldn't this also collide with ImportedIdentity values?
> > > Perhaps we are missing something even more fundamental in our
> > > reading.) ([draft-dt-tls-external-psk-guidance-01] covers similar
> > > issues in its Sec. 6.1.2, "PSK Identity Collisions.")
> >
> > Yes, certainly it's possible for a non-imported EPSK to have an identity which
> > matches the constructed identity of an imported PSK. We can't do anything
> > to prevent applications from crafting such identities, so I'm inclined to just
> > note this as a possibility, if anything.
> 
> A note would be fine.
> 
> > > b. Attack impact.  If it's possible for an opaque identifier for a
> > > non-imported EPSK identity to have the same encoding as an
> > > ImportedIdentity value, then how does the server recognize
> > > unambiguously that the opaque identifier is intended to be an imported
> > > identity?  The server could take an optimistic approach and assume
> > > that an identifier that meets the ImportedIdentity syntax is probably
> > > an imported identity, and run the code path for imported identities first.
> >
> > Yep, that's what I envisioned servers would do.
> >
> > >  If that path fails, however -- either because the server doesn't
> > > accept the EPSK or associated parameters, or because the binder value
> > > is incorrect -- then the server may need to run the code path for
> > > non-imported identities as a fallback, checking next to see if the
> > > opaque string is recognized as an ordinary EPSK identity.  But this
> > > practice just puts more burden on a server against an attacker who
> > > replays (or makes up) the PSKIdentity.identity value:  two code paths
> > > are exercised for the price of one attempted handshake.
> >
> > I don't think this is a particularly useful attack, though I do agree that it causes
> > more work for the server. I'm curious to hear what others think.
> >
> > > c.  Mitigations.  One way to reduce the burden is to impose a new
> > > requirement that the opaque string can only have the ImportedIdentity
> > > syntax if the client (or server in the case of hints) indeed intends
> > > to use the import mechanism. An ordinary EPSK could have any other
> > > value, just not this kind.  But this may not be compatible with the
> > > installed base, especially with implementations that allow clients and
> > > servers to specify arbitrary EPSK identities. (Consider the case where
> > > an application adopts the imported identity syntax for the use
> > > intended in this draft, and then decides to reuse the syntax for other
> > > purposes, including ordinary EPSK identities.)
> > >
> > > Another way to ensure distinctness is to add a flag that indicates
> > > that the PSK identity is an imported identity. But it's not clear
> > > where this flag would go, given that the PskIdentity syntax isn't extensible.
> > > Perhaps there could be an overall flag indicating that _all PSK
> > > identities are imported identities? Or a new extension for imported
> > > PSKs?
> >
> > Since this draft is meant to fix an annoyance in TLS 1.3, I think anything more
> > than a different Identity encoding is overkill. I absolutely agree that the
> > rigidity of PskIdentity is something we might want to fix. I'm just not sure
> > that should be done here.
> 
> Agreed, this would be a larger discussion.  Just wanting to be sure the 
> concern was noted in the document.
> 
> > > d.  Key separation.  Note that the foregoing discussion about EPSK
> > > identifiers potentially colliding is separate from the question about
> > > what happens if an IPSK happens to collide with a non-imported EPSK.
> > > The draft handles this effectively with different inputs to the binder
> > > derivation ("ext binder" vs. "imp binder").  But this happens after
> > > the implementation has already decided whether to interpret the
> > > identifier as external or imported.
> > >
> > > e.  Incremental deployment.  Section 6 states that " the derived PSK
> > > will not be the same [as the underlying EPSK] since the importer
> > > differentiates the PSK via the identity, target protocol and target
> > > key KDF."  However, the next statement does not follow directly:
> > > "Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
> > > 1.2, and thereby avoid cross-protocol collisions."  Rather, the
> > > statement also depends on the requirement in Section 3 that clients
> > > (and servers) don't deliberately use EPSKs or IPSKs for other
> > > purposes, and the security properties of the KDF that produces the IPSK
> > (which ensures
> > > that collisions don't occur accidentally).   But there also seems to be
> > > an implication in Section 6 that the use of the KDF in the TLS 1.3
> > > importer doesn't conflict with the cryptographic functions used for
> > > obtaining the TLS 1.2 pre-master secret.  If so, this distinction
> > > should be spelled out.
> >
> > Hmm, not quite. The statement intends to say that if you need EPSK k into an
> > importer and into TLS 1.2 then the resulting keys used in TLS 1.3 and 1.2 are
> > different. I'm not sure further clarification is needed, though I'm happy to
> > review suggestions if you have them!
> 
> Agree with that as the goal.  Here's our concern in brief.  If our 
> understanding is correct, prior to this draft, the client could use an 
> EPSK k in two ways:
> 
> * as input to the TLS 1.2 PRF (based on any hash function)
> * as input to the TLS 1.3 key schedule via HKDF-extract (based on a 
> single hash function)
> 
> Following this draft, the client could use k in two ways:
> 
> * as input to the TLS 1.2 PRF (based on any hash function) [same as 
> before]
> * as input to the importer function via HKDF-extract (based on a single 
> hash function)
> 
> So there is still a potential cryptographic overlap in the use of k 
> between TLS 1.2 and TLS 1.3.  The imported keys don't have this 
> overlap, because they're separated from one another and from the 
> underlying EPSK through the use of the importer function.  But doesn't 
> the security proof for k still need to take into account that the input 
> to HKDF-extract might also be input to the TLS 1.2 PRF (with the same 
> or a different hash function)?
>
> In other words, if it was a problem for the security proof that k could 
> be input to the PRF and to HKDF-extract before the draft, isn't it 
> still a problem afterwards?  The conclusion that there are no 
> cross-protocol collisions depends on the specifics of the TLS 1.2 PRF 
> and how it's used, compared to HKDF-extract.
> 
> We're not suggesting there is any attack here, just trying to 
> understand the design actually addresses the statement in the 
> introduction that k "could possibly be re-used in two different 
> contexts with the same hash functions during key derivation".

For lack of a better way to describe this (sorry!), we're trying to avoid this input collision during the key derivation process of a TLS connection. As the importer happens before a connection, and can be viewed as part of the provisioning process that produces unique PSKs for each target hash function, we achieve the goal for TLS 1.3 of not re-using a PSK with different hash functions. 

I'm not sure how to better clarify that right now, so suggestions are very much welcome. 

Best,
Chris