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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 21 Apr 2020 13:57:57 +0000

Here are a few comments gathered from Verisign Labs on draft-ietf-tls-external-psk-importer-04.

1. Overview of draft goals and techniques.   We've summarized our understanding of the draft here.  Our subsequent comments are based on this understanding.

a. Goal:  The draft's goal is to define a mechanism by which a TLS client and server can derive multiple, cryptographically separate imported PSKs  (IPSKs) from a single, shared external PSK (EPSK), such that each IPSK is associated with a different combination of protocol parameters (e.g., the target KDF for the TLS key schedule).  The IPSK then takes the place of the PSK input.  This goal is beneficial as it avoids the need for a client and server to establish different EPSKs for these different combinations.  The draft doesn't specify how to establish the EPSK initially (this is left out of scope, as it is in TLS itself). 

b. Mechanism:  The IPSK is derived from the EPSK and other parameters via a key derivation function associated with the EPSK.  The other parameters include a general-purpose context string, the identifier of the target protocol, and the identifier of the target KDF.  The IPSK is thereby bound to these parameters.  The binding to the target KDF helps ensure that the input key material for different KDFs are cryptographically separate. 

c. Syntax:  In support of this mechanism, the draft also specifies a new syntax for the opaque PskIdentity.identity field in the TLS PSK extension.  The new syntax includes the identity of the underlying EPSK (which remains an opaque string, as usual) and the associated protocol parameters.  When a server recognizes that the PSKIdentity.identity field has this syntax, if the server accepts the underlying EPSK and the associated parameters, the server then derives the PSK input to the TLS key schedule from the underlying EPSK and the other parameters.  A client may offer multiple IPSK identities, each with a different combination of underlying EPSK identities and associated parameters. 

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.  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.")

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.  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. 

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?

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.

Related to this, where Section 3 states, "Clients which import external keys MUST NOT use either the external keys or the derived keys for any other purpose," should "Clients" be "Clients and servers" or simply "Endpoints"?

Scott

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 21 Apr 2020 18:56:35 -0700

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://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/31

> 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. 
 
> 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.

> 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!

> Related to this, where Section 3 states, "Clients which import external 
> keys MUST NOT use either the external keys or the derived keys for any 
> other purpose," should "Clients" be "Clients and servers" or simply 
> "Endpoints"?

Yep, that's a good editorial improvement. I filed this issue to track it:

   https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/30

Thanks again for your review and feedback!

Best,
Chris

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Apr 2020 15:10:53 +0000

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Christopher Wood
> Sent: Tuesday, April 21, 2020 9:57 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-
> importer-04
>
> > example, an endpoint might identify the same EPSK with a domain name
> > in some cases and with an IP address in others.
>
>    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!

> > definition, cannot be misinterpreted as an imported PSK.  But isn't
> > the identifier of a non-imported EPSK just an opaque string?  A
> > 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.

> > 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.
>
> 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.
>
> > 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.
> 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.

> > derivation ("ext binder" vs. "imp binder").  But this happens after
> > the implementation has already decided whether to interpret the
> > identifier as external or imported.
> >
> > 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
> 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".

> > Related to this, where Section 3 states, "Clients which import
> > external keys MUST NOT use either the external keys or the derived
> > keys for any other purpose," should "Clients" be "Clients and servers"
> > or simply "Endpoints"?
>
>    https://secure-web.cisco.com/14iqE-
> IvKyzMIbRcXgwccUfg1Jfmjd0IBwnplgFvO9aogfaXjAswuQPiy8YhPoMSDQq52
> Clal4RRXTdAVhGMJ3zbqgPzm4PJnDmtl-
> lbzJXYMcF_nmRwuIbN_zYzA2BmaTCC1TTsoffzPhT_SmO68N-
> GEumtgGhjOKtrvJT0VT52ut_WJuoT0SDe8HNNuUnVr2FDmhr9FPeSA0VwR4B
> vKmC-
> E1V1WC0XCizBO3AcSsTsOSmQsu6vjV0ZVc5Z4c9zdlgjdY0fEiEVyC98ShPswiQ/h
> ttps%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external-psk-
> importer%2Fissues%2F30

Great!

> Thanks again for your review and feedback!

Welcome!

Scott

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 24 Apr 2020 16:09:15 -0700

On Thu, Apr 23, 2020, at 8:10 AM, Hollenbeck, Scott wrote:
> 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:
> 
> 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 27 Apr 2020 14:08:03 +0000

> From: Christopher Wood <[email-masked]>
> Sent: Friday, April 24, 2020 7:09 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]

[snip]

> > > 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!
> >
> > 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
> 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.
> 

We're okay with the arguments in the draft that the design preserves security proofs when the same EPSK is used to produce internal PSKs associated with different hash functions within TLS 1.3 only. However, it isn't clear enough to us how the design preserves security proofs when the same EPSK is used with both TLS 1.2 and TLS 1.3.  I don't yet have any text to suggest, because we're not sure we understand the rationale. What is the rationale for the design in that situation?

Scott