[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Binder key labels for imported PSKs
From:       "Martin Thomson" <mt () lowentropy ! net>
Date:       2019-09-05 23:46:08
Message-ID: 83b19d14-e03f-467a-9119-148bed049509 () www ! fastmail ! com
[Download RAW message or body]

That's a much better answer than I was looking for :)

That makes sense.  The gap between theory and practice here is still something that \
is worth spending some time on, but I can see how that is something that we might \
want to keep out of this document.  The goal here is simple: take a PSK that is bound \
to one KDF and apply a transform that will allow it to be used with TLS ... in a way \
where the choice of cipher suite is not constrained by the properties of that PSK.

Understanding your broader goals better leads me to conclude that issue #15 \
(https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/15) is more \
important to resolve.

On Thu, Sep 5, 2019, at 20:56, Jonathan Hoyland wrote:
> 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 <mt@lowentropy.net> 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
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > > 
> > 
> > _______________________________________________
> > 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


[prev in list] [next in list] [prev in thread] [next in thread]