I want to push on this a little harder. Not because I don't think that more
formal protections in the line of key separation are bad (they are great), but
more to dig into the real reasons driving this change. The justification I've
gotten thus far is somewhat superficial, and I want to see if there is
something fundamental that we can point at.
When we built the ext/res distinction, there was a clear problem expressed. We
had the potential for both to be used by the same servers at the same time
(though not for the same connection) and distinguishing between them was
important. It wasn't so much that agreement about provenance of keys was
important, but more what it meant for that provenance to be confused. A
resumption key implies a number of things about the new session that extend
from the previous session, whereas a straight external key does not imply the
same. If a client and server were to disagree on these properties, one might
assume properties of the resulting session that the other did not and we would
be in a bad place.
It's true that servers are in complete control over how keys are identified,
and so this could always be addressed by the server by ensuring that key
identifiers clearly distinguish between the two types. However, that
protection would be informal and ad hoc. We wouldn't guarantee that separation
by any mechanism. By applying different labels to the binder key we produce,
disagreement results in interoperability failure (both client and server could
be wrong, but at least they then agree, which is the property we really need).
As an aside, we could have used explicit labels in the protocol, but we decided
that an implicit one was better. For the record, I still think that's a good
design paradigm to apply.
The concern with the ext/res distinction doesn't seem to apply equally here.
For simplicity, I think that we should consider this a path into the "ext"
bucket, so that we have an resumption/other analysis holding (as above), and an
external/imported analysis to perform in order to arrive at the "other"
category. The question then becomes whether to fully distinguish imported PSKs
from "regular" external PSKs.
I think that the context of use is important to consider. The imported PSK
will enter the key schedule (as shown below) after having been through a
derivation process that includes additional information: most importantly, the
protocol version and the hash function that the resulting PSK will be bound to.
That produces something that could coexist with other uniformly random PSKs of
sufficient entropy (i.e., it wouldn't collide with "external" PSKs with
non-negligible probability). Because neither imported nor external PSKs come
with any different presumption about the session that is ultimately produced,
the same rationale for ext/res doesn't apply, and I'm struggling to find any
stronger justification.
The cost of adding more separation is forced changes to code. With the design
prior to this, the importer function was loosely coupled to the TLS stack. It
would be possible to manufacture as many "external" PSKs as needed from an root
"imported" PSK. The resulting outputs could be fed to endpoints that haven't
been updated to support this new importer stuff. That's obviously less clean
than having native support for this, because the amount and complexity of key
provisioning is higher, but it could have worked. This now requires code
changes to deploy.
So I'm not seeing strong cause here.
To me, the relevant question is: Do client and server need to agree that this
is an imported PSK as distinct from another form of external PSK? Or, what is
the value of this distinction?
On Tue, Sep 3, 2019, at 09:29, Christopher Wood wrote:
> Hi folks,
>
>
> Per Jonathan Hoyland's recommendation, we're considering adding a new
> binder_key label ("imp binder") for imported PSKs. Specifically, this
> changes the key schedule from this:
>
> ~~~
> 0
> |
> v
> PSK -> HKDF-Extract = Early Secret
> |
> +-----> Derive-Secret(., "ext binder" | "res binder", "")
> | = binder_key
> ~~~
>
> to this:
>
> ~~~
> 0
> |
> v
> PSK -> HKDF-Extract = Early Secret
> |
> +-----> Derive-Secret(., "ext binder"
> | | "res binder"
> | | "imp binder", "")
> | = binder_key
> ~~~
>
> Details can be found in the PR [1].
>
> This does not seem to affect the interoperability story (imported keys
> are further differentiated from non-imported keys). However, it's non
> trivial, so we'd like feedback from the group before merging the change.
>
> Thanks!
> Chris (no hat)
>
> [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
