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
