Re: [TLS] Binder key labels for imported PSKs

[Jonathan Hoyland <[e-mail]>]

Hi Martin,

So I agree that on the micro-scale there is limited practical value to be
gained from adding this binding.
The theoretical benefits, which mean that the client and server agree that
PSK Importers are being used are nice, but on their own might not justify a
high-effort change.
However, at the macro-scale I think this is an interesting and useful
addition.
In particular I think we can use this change to address what I see as a
short-coming of TLS 1.3 in general.

Being able to use TLS as a building block for other protocols is really
powerful and useful, but the current mechanisms are unnecessarily
restrictive.
I have spent a lot of time thinking about exporter keys, and the way they
let us combine other protocols with TLS.
TLS has really nice, strong, properties, and being able to leverage them in
other protocols makes designing complex protocols much easier, especially
from a formal analysis perspective.

One limitation of exporter keys, however, is that you need to use TLS as
your first/base protocol.
Whilst you can use exporter keys to securely run a protocol over the top of
TLS and get the guarantees of both*, you cannot run TLS inside another
protocol and easily get the security guarantees of both*.
I think that this restriction is unnecessary.

My overarching goal is to make it possible to securely put protocol
building blocks before TLS.
The way you would achieve this is by allowing such blocks to be chained
together and then bound into the TLS handshake.
Ideally, all protocols that wish to use TLS in this way would use this
key-schedule extension, allowing for complex state to be built up and
composed into the TLS handshake.

PSK Importers are, to my mind, a good place to start.
Agreeing on a change of hash function can be viewed as a very small, very
simple protocol.
The necessary modifications are small, and the benefits, whilst
incremental, are clear.
The modification to the key schedule means that both parties can be sure
that the other agrees that they are using PSK Importers and further, that
they agree on the original hash function and the new hash function.

Other protocols can then also make use of this extension to the key
schedule to achieve similar aims.
The idea would be that any protocol that uses this label implies that it is
providing a context field (which may or may not be empty).
These protocols can then be chained together in an agreed order, and the
agreement properties of TLS can be used to verify that both parties agree
on the transcripts of the previous protocols.

Making this change allows us to leverage this power in future to make any
number of more useful protocols.
However, without a key schedule change, there is no way for a Client and
Server to be sure that their peer is actually using TLS as a building
block, which kneecaps any ability to compose it with other protocols.
In this case it means that a Client cannot be sure that it agrees with the
Server on the status of their relationship, and vice versa.
So to directly answer your question, the value of the distinction in this
case is incremental, but opens the door for other extensions/protocols to
leverage it to provide arbitrarily complex guarantees**.

There may be a case for working on a backwards compatible way of doing
this, where a client offers PSK Importers multiple times with binders
computed both ways, but I don't think that it's necessarily a good idea.

Regards,

Jonathan

* The guarantees it is possible to get from this key-schedule change are a
little bit nuanced, because a PSK handshake doesn't rely on a long-term
asymmetric key, but that's a discussion for another time.
** Modulo limitations on outward compound authentication.


On Wed, 4 Sep 2019 at 02:46, Martin Thomson <[e-mail]> wrote:

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