Re: [TLS] [Uta] OCSP in RFC7525bis
On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor wrote: > This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a > client deliberately fail a connection when the problem might be a flaw > with an unrelated network service or a client-specific routing failure? > > I think we can definitely explicitly recommend: > > A) clients MUST require valid stapled OCSP response when encountering a > certificate with "must staple" extension. (this is just following > the specs, but i don't think it's as widely supported as it should > be; maybe we need some public naming/shaming?) > Isn't this also a "MUST, BUT WE KNOW YOU WON'T AND PROBABLY SHOULDN'T"? There are good reasons that clients have not, and potentially will never, support Must-Staple, whether it be for the technical reasons that many servers are unfit to support it, or for policy reasons, such as wanting to be careful about the security policies of their products, and how much of that is outsourced to CAs. The choice about whether to require stapling or not _is_ a policy decision relevant not only to server operators, but also relying parties, and can be easily abused by CAs if given that lever. Given the concerning practices already seen with respect to revocation, which are detrimental to the security goals of both server operators and end users, a full-throated MUST seems a bit incompatible with the notion of allowing policy flexibility. For example, in a world where a client delivers revocation information out of band, as nearly every major web browser does today (as one example), "must staple" is of questionable benefit. > So the right set of fixes to defend against all these kinds of attacks > are: > > - enable DNSSEC for your zone > > - signal in your DNS (e.g. via CAA, RFC 8659) that you only want a > specific set of CAs to issue certificates in your zone (CAA doesn't > explicitly describe an option to require that the CA use must-staple, > but it looks like any CA could declare a CAA parameter that would > offer that guidance. for example: > https://github.com/letsencrypt/boulder/issues/5903) > > - ensure that your account with those CAs requires must-staple (either > with your CA's preferred CAA parameter, or some other way) > > - monitor CT logs for certificates that violate your CAA policy > > This should close all the gaps that i can see, making the whole chain as > strong as your control over what gets signed by your zone's DNSSEC > signing key (and your CA's adherence to CAA policy, of course). > Without wanting to detract too much from the core question of the thread, how does this address the routing gap? The adversary at the routing layer just redirects the host being validated to control the key that way, and simply interrupts the nameserver during the CAA check. In the threat model you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA checks. The assumption here for this model to hold is that the CAA information is infallibly guaranteed to be delivered to the CA (it is not), and that the CA will properly adhere to it for all threats that are concerning (they do not). Without those properties, this doesn't provide any value, and that rather significantly undermines the argument for the MUST for Must-Staple being made for clients/relying parties. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] OCSP in RFC7525bis
On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote: > * Add a SHOULD-level requirement (for TLS 1.3 implementations, > possibly also TLS 1.2 implementations) to fail the handshake if the > OCSP response is missing or invalid. (As far as we can tell, RFC 8446 > is silent on this.) This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a client deliberately fail a connection when the problem might be a flaw with an unrelated network service or a client-specific routing failure? I think we can definitely explicitly recommend: A) clients MUST require valid stapled OCSP response when encountering a certificate with "must staple" extension. (this is just following the specs, but i don't think it's as widely supported as it should be; maybe we need some public naming/shaming?) I'm less sure about, but could be convinced of: B) server operators SHOULD use certificates with "must staple" extension. Figuring out how to properly incentivize (B) is the hard part. It looks a lot like the "you should adopt DNSSEC" argument. Most sysadmins find that unconvincing, because they hear it as "your network services need this additional point of failure". Plus, adopting this for your own certificates only helps in the event of secret key theft that the legit admin notices -- she can then respond by revoking the key and trusting the OCSP responder to not issue valid OCSP responses. As Victor rightly points out, a more likely threat model today is that the adversary spoofs your DNS or your routing, and uses that spoofing to get one of the ACME providers (e.g., let's encrypt) to issue new certificates entirely. So the right set of fixes to defend against all these kinds of attacks are: - enable DNSSEC for your zone - signal in your DNS (e.g. via CAA, RFC 8659) that you only want a specific set of CAs to issue certificates in your zone (CAA doesn't explicitly describe an option to require that the CA use must-staple, but it looks like any CA could declare a CAA parameter that would offer that guidance. for example: https://github.com/letsencrypt/boulder/issues/5903) - ensure that your account with those CAs requires must-staple (either with your CA's preferred CAA parameter, or some other way) - monitor CT logs for certificates that violate your CAA policy This should close all the gaps that i can see, making the whole chain as strong as your control over what gets signed by your zone's DNSSEC signing key (and your CA's adherence to CAA policy, of course). --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Revised hybrid key exchange draft
I am not convinced that the extra effort is justified.
However, I am convinced that the proposed construction is complex.
combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
data=1||F(k1)))
H1(k) = H('derive1' || k)
H2(k) = H('derive2' || k)
F(m) =
H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)
for m = m1||m2||...||mn and j =~ 3
It's nice that this is a dual PRF; that's something I think we've wanted for a
number of other reasons in TLS. I might have preferred a more efficient option
though.
Comparing that to k1 || k2 means - for me - this needs much stronger
justification.
Perhaps if the CFRG were to standardize a dual (or multi) PRF that were more
efficient I would be more favourably inclined toward its inclusion - in a
revision of the core specification.
The nice thing about the hybrid draft is that it isn't a firm commitment to any
particular combination method. Each new key exchange "group" can define its
own combination method. It only suggests a method. So I don't agree that
"[m]issing this opportunity would effectively further embed the problem" (or
maybe "effectively" is doing a little too much work there).
On Wed, Jan 19, 2022, at 22:21, Nimrod Aviram wrote:
> Hi Everyone,
>
>
> As Douglas wrote, we have discussed the issues together at length, and
> we thank him for the productive (and friendly :-)) conversation.
>
>
> Our paper, which describes our concerns, can be found here:
> https://eprint.iacr.org/2022/065
>
> And a reference implementation of our proposed KDF:
> https://github.com/nimia/kdf_reference_implementation/blob/main/kdf_reference_implementation.py#L60
>
>
> A few points from our side:
>
> Firstly, our proposed construction is simple to implement (see the
> Python code above), and adds a modest overhead of a few microseconds
> (see the paper).
>
>
> Re: point a) from Douglas’ first mail: Admittedly, our concerns are
> broader than Hybrid Key Exchange in TLS. However, we view the
> standardization of Hybrid Key Exchange as an opportunity to add defense
> in depth. Missing this opportunity would effectively further embed the
> problem. We don’t see another such opportunity on the horizon: If we
> standardize a TLS extension in a few years, getting everyone to deploy
> the extension would be hard. Whereas here everyone has to deploy the
> new thing anyway, so we might as well make it as robust as we can.
>
>
> Consider the following: SHA-1 weaknesses to collisions were first
> really highlighted in 2005. TLS version 1.0 was standardised in 2006
> and hardcoded the use of SHA-1, and MD5 (admittedly, for use in HMAC).
> TLS 1.2 was standardised in 2008, and formal deprecation of SHA-1
> occurred in 2011 by NIST. The standard deprecating the use of SHA-1 in
> TLS 1.2 digital signatures occurred in 2021. In 2016, TLS support
> (according to Qualys SSL Labs SSL survey) was over 90%. In 2020, TLS
> 1.0 support was still above 50%, despite practical chosen-prefix
> collision attacks against SHA-1 being possible. Being robust against
> future threats when given the option is something that we should
> seriously take time to consider.
>
>
> As to ekr’s response that the standard already states we need a
> collision-resistant hash function: Brendel et al. [1] proved that the
> TLS 1.3 ECDHE handshake survives losing the collision resistance of the
> hash function, as long as HKDF retains its pseudorandomness property.
> However, HKDF does not provably possess this property to begin with,
> with respect to the (EC)DH shared secret input, since this input is fed
> as the message input to HMAC, and HMAC/HKDF is not a dual PRF.
>
>
> To summarize, we recommend using our new proposed construction. It’s
> fast, easy to implement, and provides provable security. We see no
> reason to entrench a problem if we’re already changing the protocol in
> this area, and requiring implementation changes anyway.
>
>
> Best,
>
> Nimrod, Ben, Ilan, Kenny, Eyal, and Eylon
>
>
> [1] https://www.felixguenther.info/publications/ESORICS_BreFisGun19.pdf
>
>
>
>
> On Tue, 11 Jan 2022 at 21:08, Douglas Stebila wrote:
>> Hello TLS working group,
>>
>> We've posted a revised version of "Hybrid key exchange in TLS 1.3" [1].
>> Based on revision requests from the last draft, the main change is removing
>> the unnecessary appendix of the past design considerations, and a few
>> wording changes.
>>
>> Last September, Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny
>> Paterson, Eyal Ronen, and Eylon Yogev posted a note [2,3] with some concerns
>> about whether the approach for constructing the hybrid shared secret in this
>> document -- direct concatenation -- was risky in a scenario where the hash
>> function used in TLS key derivation and transcript hashing is not collision
>> resistant. Nimrod and his colleagues exchanged many emails with us over the
>> past few months
Re: [TLS] OCSP in RFC7525bis
On Thu, Jan 20, 2022 at 8:41 AM Hanno Böck wrote: > Thus even if you think OCSP stapling and the whole process of revocation > is useless, there are still good reasons for a server operator to enable > stapling: > 1. It avoids an extra connection for clients to the OCSP server, thus > making client connections potentially faster. > 2. It avoids a potential privacy issue for clients who would otherwise > leak their intent to connect to a specific host to their CA. Without wanting to debate the merits too much, because I am cognizant that opinions are mixed, I would want to push back on the first assertion there. >From a server perspective, this involves potentially sending the response on every connection, where a client initiated (or out of band delivered) request would amortize that cost over the lifetime of the response. That is, in the context of RFC 5019, which has long been seen as the only “internet scale” way to deliver OCSP (by leveraging HTTP and intermediary/CDN caching), the client doesn’t need to request a new response for the lifetime of the response/caching directives. However, in the server stapled case, it is not able to effectively / safely slide that. There was a lot of discussion about this imbalance during the discussion of TLS cached info, and the tradeoffs there, but I hope we can agree that even then, it’s not widely supported. In practice, for most clients, OCSP stapling will add non-trivial overheads to the connection establishment, especially given the lack of widely adopted OCSP response profiles and practices (e.g. CAs including more certificates than necessary). I don’t dispute the theoretical value of your second point, and the nature of the chicken-and-egg problem of “If a client wants privacy, should it rely on the server to change, or should it change” (which we see similarly playing out with things like DoH or ECH). However, it’s worth highlighting that OCSP stapling is not the only way to achieve those privacy goals, and it’s not as low cost as your first point suggests. Unsurprisingly, this means I agree with EKRs recommendations for the path forward on this draft, namely, avoiding the SHOULD. It would be interesting to explore that tradeoff space, as he suggests, but I realize that this discussion likely highlights that it will be a delicate needle to thread to do so in a timely fashion. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
Hi Hannes, This is not about my personal beliefs. RFC 7525 looks at certificate revocation in the context of TLS (and not only TLS for Web use but the broader ecosystem) and recommends OCSP and OCSP Stapling as the best available techniques to enable effective certificate revocation, but with caveats. It’s been more than 6 years since the RFC was published, and we are reviewing our recommendations, which may or may not still be valid. Thanks, Yaron From: Hannes Tschofenig Date: Thursday, January 20, 2022 at 12:00To: Yaron Sheffer , u...@ietf.org , tls@ietf.org Subject: RE: OCSP in RFC7525bisHi Yaron, Where do you believe OCSP will be a good fit and why? CiaoHannes From: TLS On Behalf Of Yaron ShefferSent: Wednesday, January 19, 2022 3:57 PMTo: u...@ietf.org; tls@ietf.orgSubject: [TLS] OCSP in RFC7525bis Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if they don’t get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it’s trying to solve. So for the new BCP, we have three options:1. Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)2. Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.3. Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit. We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be very useful. Thanks, Peter, Thomas and Yaron PS: apologies for cross-posting. [1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5[2] https://github.com/yaronf/I-D/pull/279/files[3] https://cbw.sh/static/pdf/chung-imc18.pdf IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
Reading the discussion so far I want to raise something to consider. There are separate questions that shouldn't be confused: 1. Is OCSP stapling with soft-fail (absent further enforcement mechanisms like muststaple) actually useful? 2. Should server operators enable OCSP stapling? For 1. one can reasonably argue that it is not, as an attacker can potentially rely on the softfail property. However for a server operator the question isn't just whether OCSP stapling serves its purpose. A server operator naturally will have to deal with a variety of clients that have a variety of behaviors. Some clients will do OCSP requests when no stapled response is sent. Thus even if you think OCSP stapling and the whole process of revocation is useless, there are still good reasons for a server operator to enable stapling: 1. It avoids an extra connection for clients to the OCSP server, thus making client connections potentially faster. 2. It avoids a potential privacy issue for clients who would otherwise leak their intent to connect to a specific host to their CA. tl;dr I think enabling OCSP stapling on servers almost always makes sense. -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
Hi Yaron, Where do you believe OCSP will be a good fit and why? Ciao Hannes From: TLS On Behalf Of Yaron Sheffer Sent: Wednesday, January 19, 2022 3:57 PM To: u...@ietf.org; tls@ietf.org Subject: [TLS] OCSP in RFC7525bis Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961. But this raises a larger question: many client-side implementations soft-fail if they don’t get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it’s trying to solve. So for the new BCP, we have three options: * Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.) * Remove the whole discussion of OCSP, saying that in its current form it’s not adding value. * Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit. We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be very useful. Thanks, Peter, Thomas and Yaron PS: apologies for cross-posting. [1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5 [2] https://github.com/yaronf/I-D/pull/279/files [3] https://cbw.sh/static/pdf/chung-imc18.pdf IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
