Hi folks, Since #15 has been resolved, we'd like to revisit the proposed key schedule label modification here:
https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 Please have a look and comment! Thanks, Chris On Thu, Sep 5, 2019, at 4:46 PM, Martin Thomson wrote: > 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 <m...@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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
