On Thu, Apr 23, 2020, at 8:10 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: TLS <tls-boun...@ietf.org> On Behalf Of Christopher Wood > > Sent: Tuesday, April 21, 2020 9:57 PM > > To: TLS@ietf.org > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
