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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
