IronPort-SDR: svimTqIqvwDgDK7C7iJ3w2jby28l58lX01Y5lVfSThfqXy5jj1smXaJd9LWH8CIioELlrcb+9p
 66JPODwbN9lvqQ+SQvAoxYHwrHlBJPTZFrFe56lVEhGlQxVvsvdoDWnUtF5Dg4dLSLIdmq9GBZ
 S9MP2EuHXcMoFwFYmKIkC8sBu62v3RrM90MzcFo7XQfXRdNUSs6DrPwDQJpwoY/0EOb1+ze0Ar
 Zlg6JIkKupZSRrbZI4siJVw/xzcbG+S3MOg0tFMKgIaYjVJh6sTb0YE3nNubMShTIOGq1CRT+0
 tFQ=
IronPort-PHdr: =?us-ascii?q?9a23=3AHj+1sRzKkRpRo0zXCy+O+j09IxM/srCxBDY+r6?=
 =?us-ascii?q?Qd1OMfIJqq85mqBkHD//Il1AaPAdyGra4ZwLSG+4nbGkU4qa6bt34DdJEeHz?=
 =?us-ascii?q?Qksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPER?=
 =?us-ascii?q?vjKwV1Ov71GonPhMiryuy+4ZLebxhIiTanbr5/LBq6oATSu8ILnYZsN6E9xw?=
 =?us-ascii?q?fTrHBVYepW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH?=
 =?us-ascii?q?0169bwtRbfVwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXz?=
 =?us-ascii?q?mp8qFmQwLqhigaLT406GHZhNJtgqJHrhyvpB1/zJLbbo6aL/d+YrrdfdEGSW?=
 =?us-ascii?q?ZdQspdSSpMCZ68YYsVCOoBOP5Vo4f/qVsJqRu+ARejBOX0xTBWmnD23rU22P?=
 =?us-ascii?q?k8Hw7a2wwgA84OvHrJp9jyL6cSUee1zK3MzTrdafNZwiny55TLch06v/GDQ6?=
 =?us-ascii?q?hwccvKyUkuGAPFiE+cppDiPzOQz+kAtXWQ4el4Ve+3lmIrtxt9riWty8oikI?=
 =?us-ascii?q?XFm4IYx17e+Sh2xIs5PcC0RFJhbdK5EpZcqzuWO5Z5T84hWW1kpSU3x7sbsp?=
 =?us-ascii?q?ChZicK0o4oxxvHZvyCdIiH/wzsWf6KITd9mHJlYLW/hwuu8US4yu3zSM200F?=
 =?us-ascii?q?FSoydYjtfCrm0B2BzL5MaIS/Rx4lmt1SyR1w/P7eFEO1g0mbDBJJE82LIwiI?=
 =?us-ascii?q?ATsV/FHiPshEr2i6qWel0l+uiu9evnfq3rqoKAO4Nulw3zMKojltaiDek4PA?=
 =?us-ascii?q?UCRWeW9OCk2L3m50L5QbFKjvMskqnetZDXPd8bpq6+Aw9R1oYs9RC/ACy439?=
 =?us-ascii?q?sEnnkKN0xFdwydj4joIFHOIf/4DfGlj1uwlzdrwujKPqf9DZXVMnjDjLDhcK?=
 =?us-ascii?q?5j5UBa1QQ+1tFf6IxICrEPOv7zXVXxtNOLRiM+ZkaI593PCdhh2MUZQ23FSv?=
 =?us-ascii?q?ulFJj6sFKU6KQoOebaN6EPvzOoYdgi4/rji3U0klxZNZKi2ocLIjjsBfRhJ0?=
 =?us-ascii?q?GUZ3DhidQpD2oQvxE/Q+qsg1qHB20AL02uVr4xs2loQLmtCp3OE9ig?=
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: Comments on draft-ietf-tls-external-psk-importer-04
Thread-Index: AdYX4WFdhLPIgsQ4RUymyBbaAf5mxQ==
Date: Tue, 21 Apr 2020 13:57:57 +0000
Message-ID: <fb7c3f894dfa49efb5917d2e39c4ea78@verisign.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/d7ktdMu645J9pMhHB_Rgnx4R1X0>
Subject: [TLS] Comments on draft-ietf-tls-external-psk-importer-04
Precedence: list

Here are a few comments gathered from Verisign Labs on draft-ietf-tls-exter=
nal-psk-importer-04.

1. Overview of draft goals and techniques.   We've summarized our understan=
ding of the draft here.  Our subsequent comments are based on this understa=
nding.

a. Goal:  The draft's goal is to define a mechanism by which a TLS client a=
nd server can derive multiple, cryptographically separate imported PSKs  (I=
PSKs) from a single, shared external PSK (EPSK), such that each IPSK is ass=
ociated with a different combination of protocol parameters (e.g., the targ=
et 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 ser=
ver to establish different EPSKs for these different combinations.  The dra=
ft doesn't specify how to establish the EPSK initially (this is left out of=
 scope, as it is in TLS itself).=20

b. Mechanism:  The IPSK is derived from the EPSK and other parameters via a=
 key derivation function associated with the EPSK.  The other parameters in=
clude a general-purpose context string, the identifier of the target protoc=
ol, and the identifier of the target KDF.  The IPSK is thereby bound to the=
se parameters.  The binding to the target KDF helps ensure that the input k=
ey material for different KDFs are cryptographically separate.=20

c. Syntax:  In support of this mechanism, the draft also specifies a new sy=
ntax for the opaque PskIdentity.identity field in the TLS PSK extension.  T=
he new syntax includes the identity of the underlying EPSK (which remains a=
n opaque string, as usual) and the associated protocol parameters.  When a =
server recognizes that the PSKIdentity.identity field has this syntax, if t=
he server accepts the underlying EPSK and the associated parameters, the se=
rver then derives the PSK input to the TLS key schedule from the underlying=
 EPSK and the other parameters.  A client may offer multiple IPSK identitie=
s, each with a different combination of underlying EPSK identities and asso=
ciated parameters.=20

2. Technical comments.=20

a. Distinct identities?  Sec. 3 states "Non-imported and imported PSKs are =
distinct since their identities are different on the wire."  We have two co=
ncerns about this statement.  First, the statement appears to suggest that =
if two EPSKs have different identities, then they must have different secre=
t values.  But couldn't two EPSKs have the same secret value yet employ dif=
ferent 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 o=
thers.  Second, and more fundamentally, the statement assumes that a non-im=
ported EPSK, by definition, cannot be misinterpreted as an imported PSK.  B=
ut isn't the identifier of a non-imported EPSK just an opaque string?  A no=
n-imported EPSK identity could therefore have the same "bits on the wire" a=
s an IPSK identity, if the client and server employ an identifier system th=
at whose encoding happens to coincide with the ImportedIdentity structure d=
efined in the draft.  (Moreover, the identifier of a resumption PSK is just=
 an opaque string -- so couldn't this also collide with ImportedIdentity va=
lues?  Perhaps we are missing something even more fundamental in our readin=
g.)  ([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-impo=
rted 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 optimist=
ic approach and assume that an identifier that meets the ImportedIdentity s=
yntax 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 va=
lue is incorrect -- then the server may need to run the code path for non-i=
mported identities as a fallback, checking next to see if the opaque string=
 is recognized as an ordinary EPSK identity.  But this practice just puts m=
ore burden on a server against an attacker who replays (or makes up) the PS=
KIdentity.identity value:  two code paths are exercised for the price of on=
e attempted handshake.=20

c.  Mitigations.  One way to reduce the burden is to impose a new requireme=
nt 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 me=
chanism. An ordinary EPSK could have any other value, just not this kind.  =
But this may not be compatible with the installed base, especially with imp=
lementations that allow clients and servers to specify arbitrary EPSK ident=
ities. (Consider the case where an application adopts the imported identity=
 syntax for the use intended in this draft, and then decides to reuse the s=
yntax for other purposes, including ordinary EPSK identities.) =20

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 w=
ould 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 identifi=
ers 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 binde=
r" vs. "imp binder").  But this happens after the implementation has alread=
y decided whether to interpret the identifier as external or imported.=20

e.  Incremental deployment.  Section 6 states that " the derived PSK will n=
ot be the same [as the underlying EPSK] since the importer differentiates t=
he 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 Sect=
ion 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 IP=
SK (which ensures that collisions don't occur accidentally).   But there al=
so seems to be an implication in Section 6 that the use of the KDF in the T=
LS 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 key=
s MUST NOT use either the external keys or the derived keys for any other p=
urpose," should "Clients" be "Clients and servers" or simply "Endpoints"?

Scott