Re: [TLS] Binding imported PSKs to KDFs rather than hash functions
Hi Martin,
Thanks for the reply! Please see inline below.
On Mon, Sep 16, 2019, at 6:26 PM, Martin Thomson wrote:
> There are two points here to consider:
>
> 1. Whether the key that we are feeding into this process is going to be
> used exclusively for that purpose, or whether it might be used for
> something else.
>
> 2. How the key that is output from this process might need diversification.
>
> What we learned from TLS 1.3 is that HKDF is effectively a completely
> different KDF when it is used with a different hash function. And that
> taking the same key into two different functions was not advisable
> because there isn't a lot of analysis to support that particular usage
> pattern.
>
> In thinking about the first point, we might want to consider whether
> the KDF that is used in the importer might need to be used in other
> ways.
To be clear, you're referring to HKDF and its role in deriving ipsk from epsk,
right?
> Personally, when I see the question formulated this way, I am
> inclined to suggest that this key should be used exclusively for key
> import. If that's the decision, that should be made very clear.
I agree. We can state something along the lines of "clients MUST NOT use an
external TLS PSK for any other purpose." And also say that external PSKs can
only be associated with a single hash function. As you mention above and in
your followup message, if this isn't done, then a client may import the same
IKM using different hash functions.
Is this what you had in mind?
> If we decide that we're gaining exclusive access, then the only other
> consideration I'm aware of on the input side is the binding to the
> origination of the key, as raised by Jonathan. That is something we
> might gain by integrating something into the identity, or by adding a
> context attribute to the expansion (which might carry a session hash).
> That concern is not reflected in the proposal here though.
>
> If you have exclusive access to the input keying material, then you can
> very easily restrict this to HKDF. If not, then I'd suggest that you
> need to use the more general form. But then you also need to ensure
> that whatever inputs you feed into the KDF can't collide with inputs
> for the other usages. That's tricky.
Right. Tricky and likely impossible. There's nothing stopping someone from
crafting a PSK with an identity which matches an ImportedIdentity, and then
advertising that on the wire.
> Then the question is how we identify the diversification parameters.
> Right now, we want to diversify outputs based on TLS version and the
> hash algorithm associated with the cipher suite. If this is only ever
> used for TLS, then we have a simple process: we identify the specific
> type of TLS PRF somehow and bake that into the KDF label.
>
> How we do that is simple mechanics: each version of TLS we care about
> has a template KDF, which is parameterized by hash function. As Chris
> proposes, we could include a TLS version and a hash function
> identifier. That seems enough.
I suspect you meant "KDF identifier" here? (The proposal below uses the TLS
version and a KDF identifier. It could also use the TLS version and a
HashAlgorithm value. Using a KDF identifier is probably more future proof,
though.)
> The final question is about multiple PRFs in TLS 1.2. We never
> restricted input PSKs in TLS 1.2 to a single KDF, so in theory we could
> use a single output of this importer function for TLS 1.2. However,
> I'm not sure that this is necessary if we allow for the possibility of
> an importer. We could use different keys depending on the final
> selection of cipher suite (and therefore hash function). I don't see
> any reason not to fix TLS 1.2 PSK usage at the same time as TLS 1.3.
Sure, it's possible, though I think that's already done? Was there something
below or in the draft that made you think otherwise?
Thanks again!
Chris
>
> On Sun, Sep 15, 2019, at 00:53, Christopher Wood wrote:
> > Hi folks,
> >
> > Martin reviewed the external PSK draft [1] and filed a couple issues
> > [2,3] that are worth discussion here. I’d like to call attention to #16
> > [3] in particular.
> >
> > TL;DR: Should we bind the importer to a KDF rather than a hash function?
> >
> > Currently, the importer draft assumes that an external PSK is
> > optionally associated with some hash function, and, if not, assumes
> > SHA256. The importer uses this hash function when deriving the imported
> > key. In particular, it’s the hash function used for HKDF-Extract and
> > HKDF-Expand, which runs over the external PSK blob and the constructed
> > ImportedIdentity to produce a unique, imported PSK. ImportedIdentity is
> > the structure that contains the external PSK identity, a protocol
> > label, and target hash function:
> >
> > ~~~
> > struct {
> > opaque external_identity<1...2^16-1>;
> > opaque label<0..2^8-1>;
> > HashAlgorithm hash;
> > } Imp
[TLS] Éric Vyncke's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-tls-sni-encryption-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ -- COMMENT: -- Thank you for the work put into this document. It is well-written and easy to follow. Please find below a couple of comments and nits. Reading " In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises." in the abstract brought a smile on my face ;-) Same for "employees of the UK National Cyber Security Centre" at the end ;-) Regards, -éric == COMMENTS == -- Section 2.1 -- C.1) I would suggest to use the words "network operators" rather than ISP as enterprise or parents for home networks are also relying on clear-text SNI to enforce some policies. -- Section 2.2 -- C.2) The word "abuses" seems a little strong in the first paragraph, I prefer the wording used in 2.1 "unanticipated usage". But, this is only one comment. -- Section 3.6 -- C.3) It is rather a question for my own curiosity... "The fronting service could be pressured by adversaries. " is an obvious attack but even if SNI is protected, the fronting service can still apply any policy to a protected service as it has the knowledge of protected services by design. Hence, I wonder why this case is mentioned here. -- Security section -- Like Warren, I find the content of this section unusual. == NITS == -- Section 2.1 -- Probably worth expanding "MITM" at first use. --Section 3.3 -- Probably worth expanding "DOS" at first use. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
> --Section 3.3 -- > Probably worth expanding "DOS" at first use. Actually, "DoS" (with the small "o") is in the RFC Editor's list of abbreviations that do not need to be expanded. That, of course, doesn't mean that it *shouldn't* be expanded. But it should be spelled with the small "o", in any case. Barry ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Binding imported PSKs to KDFs rather than hash functions
On Wed, Sep 18, 2019, at 00:56, Christopher Wood wrote: > > In thinking about the first point, we might want to consider whether > > the KDF that is used in the importer might need to be used in other > > ways. > > To be clear, you're referring to HKDF and its role in deriving ipsk > from epsk, right? Right. Though I see epsk -> ipskx in the draft. Not sure why that has an 'x'. > I agree. We can state something along the lines of "clients MUST NOT > use an external TLS PSK for any other purpose." And also say that > external PSKs can only be associated with a single hash function. As > you mention above and in your followup message, if this isn't done, > then a client may import the same IKM using different hash functions. > > Is this what you had in mind? Yeah. `epsk` can only be used for importation into TLS using this mechanism and only with a single hash function. > Right. Tricky and likely impossible. There's nothing stopping someone > from crafting a PSK with an identity which matches an ImportedIdentity, > and then advertising that on the wire. We can't stop all the bad ideas :) One thing that bothers me a little: how did you plan to identify these? I imagine that you would only need to identify the epsk in the TLS handshake. You don't plan to use some derived means of identification, do you? The doc is light on details here and could probably use some text on this point. > I suspect you meant "KDF identifier" here? (The proposal below uses the > TLS version and a KDF identifier. It could also use the TLS version and > a HashAlgorithm value. Using a KDF identifier is probably more future > proof, though.) Yeah, a KDF identifier is more robust, for sure. It is probably not coincidence that version+hash is enough for now, but we can be a tad more general in the interests of making this more robust. > Sure, it's possible, though I think that's already done? Was there > something below or in the draft that made you think otherwise? Probably just the discussions on GitHub and the lack of discrete identifiers for the TLS 1.2 KDFs in the IANA section. If we're identifying KDFs, then we should identify TLS 1.2 KDF separately from the TLS 1.3 ones. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's Yes on draft-ietf-tls-sni-encryption-05: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-tls-sni-encryption-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ -- COMMENT: -- Thanks to everyone who worked on this. It seems that it will be a useful tool for evaluating potential solutions. --- §3.1: > Regardless of the encryption used, > these designs can be broken by a simple replay attack, which works as > follow: Nit: "...as follows:" --- §3.6: > These solutions offer more protection against a Man-In-The- > Middle attack by the fronting service. The downside is the the > client will not verify the identity of the fronting service with > risks discussed in , but solutions will have to mitigate this risks. This final sentence appears to be missing some kind of citation before the comma. --- §3.6: > Adversaries can also attempt to hijack the traffic to the > regular fronting server, using for example spoofed DNS responses or > spoofed IP level routing, combined with a spoofed certificate. It's a bit unclear why this is described as part of the injection of a third party into the scenario. As far as I understand, the described attack exists today, in the absence of any SNI encrypting schemes. If there's a new twist introduced by a multi-party security context, the current text doesn't seem to explain what it is. --- §3.7: > Multiple other applications currently use TLS, including for example > SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. Nit: "...including, for example, SMTP..." Nit: "...and XMPP..." > These applications > too will benefit of SNI encryption. HTTP only methods like those > described in Section 4.1 would not apply there. Nit: "...benefit from SNI..." Nit: "HTTP-only..." --- §4.2: > This requires a > controlled way to indicate which fronting ferver is acceptable by the > hidden service. Nit: "...server..." --- §7: > Thanks to Stephen Farrell, Martin Rex Martin Thomson > and employees of the UK National Cyber Security Centre for their > reviews. I think you're missing a comma between the two Martins. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
