[TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
I am not very familiar with IETF working group practices, however it strikes me as surely unusual to have a document enter Last Call (supposedly believed by its owners to be ready for publication) and yet immediately then be revised showing it was in fact not ready at all. However this seems to be what happened to draft-ietf-opsec-ns-impact. The below comments concern draft-ietf-opsec-ns-impact-02, the newer document. Section 4.1 Perfect Forward Secrecy ends: > TLS session data.ss I think this is a typographical error and the trailing "ss" should be removed from the document. If not it should be explained. Section 4.2 Encrypted Server Certificate describes a practice which is inherently unsound. Passive inspection of the Certificate message from TLS 1.2 or earlier isn't a reliable source of information because a passive eavesdropper isn't able to discern whether the X.509 document presented corresponds to this server or not. The Client can confirm this using the TLS protocol but an eavesdropper can't. So the change in TLS 1.3 does not impact the practical security policy available, only an appearance is altered. Passive systems described throughout Section 5.1 fall to this same error, using the phrase "reduced effectiveness" which the document defines as not being "as effective on TLS 1.3 traffic" but in fact since this practice didn't work, it will remain exactly as effective (not at all) as before. A related consequence passes into Section 5.2. Since the Certificate message is only reliable for a Client, it has in fact always been necessary to fully proxy the TLS session in order to rely on this data, so this is not in fact an impact from TLS 1.3 but (if it wasn't done previously for all versions) a vulnerability in such products. As it stands then, this document is misleading. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS WG Virtual Interim on ECH
The chairs would like to have an interim to resolve the remaining open issues for ECH. Since we need 2 weeks notice we are targeting the week of September first. Please fill out the following with your available times if you are interested in attending: https://doodle.com/poll/wa4633uafmvdr9hv We might make this a recurring meeting until we can resolve all the issues. Please respond by the evening of Tuesday August 18. Thanks, Joe and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] ECH usage indication: alternatives to trial decryption?
Hi list, In the current ECH specification (draft-ietf-tls-esni-07), the server provides no indication of whether the inner or outer ClientHello (CH) was used. This means the client must do trial decryption to make this determination, which creates implementation complexity and potentially raises security concerns. I was hoping to get your thoughts on a couple alternatives, which strike different balances between implementation complexity and other design considerations for ECH. Follow along here: https://github.com/tlswg/draft-ietf-tls-esni/issues/274 Thanks, Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Constraining ECH to HKDF-based HPKE ciphersuites
HPKE recently removed the Hash() interface from the KDF, which means we need to either (a) change how the config_digest (formerly record_digest) is computed, or (b) constrain ECH to HKDF-based HPKE ciphersuites. This PR takes approach (b): https://github.com/tlswg/draft-ietf-tls-esni/pull/271 Please have a look and provide feedback. Thanks, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] ECH padding edge cases
Ben Schwartz found some problems and edge cases with the current ECH padding policy text [1]. This PR proposes a fix: https://github.com/tlswg/draft-ietf-tls-esni/pull/268 Please have a look and provide feedback. Thanks, Chris [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/252 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ECH usage indication: alternatives to trial decryption?
Thanks for writing this up! We've been pondering this subject as well, as part of identifying places where ECH and QUIC interact interestingly. (The other being the padding issue in https://github.com/tlswg/draft-ietf-tls-esni/issues/264.) As with the padding issue, QUIC replaces the record layer, so all the handshake/record-layer coordination here must cross the TLS/QUIC public API. TLS must configure two different keys for QUIC, then QUIC must trial decrypt and report back to TLS which keys were used. In contrast, something that lives entirely in the handshake should apply to QUIC without modifications. I think in essence we’re running into QUIC sandwiching itself between the TLS handshake and records layer, despite that “interface” not being quite fully understood yet. (I'm not sure what's IETF email etiquette for joining related WGs to an existing thread, so I'll forward this separately to the QUICWG, so they can join the discussion.) David On Mon, Aug 17, 2020 at 4:55 PM Christopher Patton wrote: > Hi list, > > In the current ECH specification (draft-ietf-tls-esni-07), the server > provides no indication of whether the inner or outer ClientHello (CH) was > used. This means the client must do trial decryption to make this > determination, which creates implementation complexity and potentially > raises security concerns. I was hoping to get your thoughts on a couple > alternatives, which strike different balances between implementation > complexity and other design considerations for ECH. Follow along here: > > https://github.com/tlswg/draft-ietf-tls-esni/issues/274 > > Thanks, > Chris P. > > > ___ > 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
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
On Tue, Aug 18, 2020, at 07:09, Christopher Wood wrote: > HPKE recently removed the Hash() interface from the KDF, which means we > need to either (a) change how the config_digest (formerly > record_digest) is computed, or (b) constrain ECH to HKDF-based HPKE > ciphersuites. This PR takes approach (b): > >https://github.com/tlswg/draft-ietf-tls-esni/pull/271 > > Please have a look and provide feedback. Was there discussion about just defining a set of hash function identifiers and adding those to the config? Or maybe just running the HPKE KDF with a fixed input. Unless I've missed something critical, you don't need any sort of preimage resistance for this, it's only for identification purposes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
Hi Martin,
> Or maybe just running the HPKE KDF with a fixed input.
Do you mean something like this? Let `config_digest = KDF.extract("some
salt", "some label", config)`, where `config` is the ECH configuration?
Unless I've missed something critical, you don't need any sort of preimage
> resistance for this, it's only for identification purposes.
>
The manner in which `config_digest` is computed could be significant to
"don't stick out", depending on how you define this property. For example,
one requirement for the hash function might be that it is one-way.
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
On Tue, Aug 18, 2020, at 07:55, Christopher Patton wrote:
> Hi Martin,
>
> > Or maybe just running the HPKE KDF with a fixed input.
> Do you mean something like this? Let `config_digest = KDF.extract("some
> salt", "some label", config)`, where `config` is the ECH configuration?
Sure. I would probably use all of HKDF though, see below.
> > Unless I've missed something critical, you don't need any sort of
> preimage resistance for this, it's only for identification purposes.
> The manner in which `config_digest` is computed could be significant to
> "don't stick out", depending on how you define this property. For
> example, one requirement for the hash function might be that it is
> one-way.
So the current system has the property that anyone in possession of the
original config can confirm that this is the config in use. And we have
assumed that the config does not contain secrets.
Being unable to recover one input seems to be a KDF property. We could feed
config to that input (for the full HKDF, that would be IKM, I think). See
definition 7 in https://eprint.iacr.org/2010/264.pdf, which supports the theory
that a KDF is a PRF with respect to at least one input (\sigma in the same).
I think that the only case where being able to compute the inverse becomes
interesting is if the config contains a secret. Let's say that you use a
config that includes a PSK. The answer there could just be "don't do that
then". Or we could work something out (for example, a nonce of sufficient
length might ensure that a secret could not be reconstructed even if everything
else were predictable).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
Just to be clear, you're proposing something like this? Referring to the
KDF API called for in draft-irtf-cfrg-hpke-05:
config_digest = Expand(PRK=Extract("some_salt", "some_label", IKM=config),
"some_info", 16)
It's maybe more hashing than necessary, but I'd be good with this.
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
On Mon, Aug 17, 2020, at 3:30 PM, Martin Thomson wrote:
>
>
> On Tue, Aug 18, 2020, at 07:55, Christopher Patton wrote:
> > Hi Martin,
> >
> > > Or maybe just running the HPKE KDF with a fixed input.
> > Do you mean something like this? Let `config_digest = KDF.extract("some
> > salt", "some label", config)`, where `config` is the ECH configuration?
>
> Sure. I would probably use all of HKDF though, see below.
If we're going to use all of HKDF (extract + expand), then let's just use the
HPKE's Extract+Expand functions in sequence.
Best,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
On Tue, Aug 18, 2020, at 09:04, Christopher Patton wrote:
> Just to be clear, you're proposing something like this? Referring to
> the KDF API called for in draft-irtf-cfrg-hpke-05:
>
> config_digest = Expand(PRK=Extract("some_salt", "some_label",
> IKM=config), "some_info", 16)
> It's maybe more hashing than necessary, but I'd be good with this.
Something like that yeah. And yes, that's a lot of hashing. But that's a
lower-order concern. Maybe if we try to find a KDF that doesn't cost so much
to operate we won't feel so bad about this.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
I worked out this suggestion into a PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/276
Please have a look!
Chris P.
On Mon, Aug 17, 2020 at 4:28 PM Martin Thomson wrote:
>
>
> On Tue, Aug 18, 2020, at 09:04, Christopher Patton wrote:
> > Just to be clear, you're proposing something like this? Referring to
> > the KDF API called for in draft-irtf-cfrg-hpke-05:
> >
> > config_digest = Expand(PRK=Extract("some_salt", "some_label",
> > IKM=config), "some_info", 16)
> > It's maybe more hashing than necessary, but I'd be good with this.
>
> Something like that yeah. And yes, that's a lot of hashing. But that's a
> lower-order concern. Maybe if we try to find a KDF that doesn't cost so
> much to operate we won't feel so bad about this.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-subcerts
Dear Nick and list, The PR is here now: https://github.com/tlswg/tls-subcerts/pull/79 Looking forward to been submitted to WGLC#2. Thanks! -- Sofía Celi @claucece http://claucece.github.io/ Cryptographic research and implementation at many places, but mainly at Cloudflare FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
