Re: [TLS] Merkle Tree Certificates
On Thursday, 23 March 2023 03:00:53 CET, Kampanakis, Panos wrote: Hi Hubert, I totally agree on your points about time-to-first-byte vs time-to-last-byte. We (some of my previous work too) have been focusing on time-to-first byte which makes some of these handshakes look bad for the tails of the 80-95th percentiles. But in reality, the time-to-last-byte or time-to-some-byte-that-makes-the-user-think-there-is-progress would be the more accurate measurement to assess these connections. Neither cached data nor Merkle tree certificates reduce round-trips Why is that? Assuming Dilithium WebPKI and excluding CDNs, QUIC sees 2 extra round-trips (amplification, initcwnd) and TLS sees 1 (initcwnd). Trimming down the "auth data" will at least get rid of the initcwnd extra round-trip. I think the Merkle tree cert approach fits in the default QUIC amplification window too so it would get rid of that round-trip in QUIC as well. I meant it on TLS level. Sure, on TCP level the less data you need to send the less problem you have with congestion window. But even there, I don't see insurmountable problems with it; even with 3 Dilithium certs, with 2 SCTs each, we're talking about 22kB of data; that's half of what cloudflare found to be an inflection point for extra data: https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ So I'm very unconvinced that for good general web browsing experience Merkle Tree Certs will be qualitatively better than cached info. -Original Message- From: Hubert Kario Sent: Wednesday, March 22, 2023 8:46 AM To: David Benjamin Cc: Kampanakis, Panos ; ; Devon O'Brien Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Tuesday, 21 March 2023 17:06:54 CET, David Benjamin wrote: On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote: On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: ... I'm not seeing where this quote comes from. I said it had analogous properties to resumption, not that it was a privacy problem in the absolute. I meant it as a summary not as a quote. The privacy properties of resumption and cached info on the situation. If you were okay correlating the two connections, both are okay in this regard. If not, then no. rfc8446bis discusses this: https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#appendix-C.4 In browsers, the correlation boundaries (across *all* state, not just TLS) were once browsing-profile-wide, but they're shifting to this notion of "site". I won't bore the list with the web's security model, but roughly the domain part of the top-level (not the same as destination!) URL. See the links above for details. That equally impacts resumption and any hypothetical deployment of cached info. So, yes, within those same bounds, a browser could deploy cached info. Whether it's useful depends on whether there are many cases where resumption wouldn't work, but cached info would. (E.g. because resumption has different security properties than cached info.) The big difference is that tickets generally should be valid only for a day or two, while cached info, just like cookies, can be valid for many months if not years. Now, a privacy focused user may decide to clear the cookies and cached info daily, while others may prefer the slightly improved performance on first visit after a week or month break. It also completely ignores the encrypted client hello ECH helps with outside observers correlating your connections, but it doesn't do anything about the server correlating connections. In the context of correlation boundaries within a web browser, we care about the latter too. How's that different from cookies? Which don't correlate, but cryptographically prove previous visit? ... I don't think that's quite the right dichotomy. There are plenty of reasons to optimize for the first connection, time to first bytes, etc. Indeed, this WG did just that with False Start and TLS 1.3 itself. (Prior to those, TLS 1.2 was 2-RTT for the first connection and 1-RTT for resumption.) ... In my opinion time to first byte is a metric that's popular because it's easy to measure, not because it's representative. Feel free to point me to double blind studies with representative sample sizes showing otherwise. Yes, reducing round-trips is important as latency of connection is not correlated with bandwidth available. But when a simple page is a megabyte of data, and anything non trivial is multiple megabytes, looking at when the first byte arrives it is completely missing the bigger picture. Especially when users are trained to not interact with the page until it fully loads (2018 Hawaii missile alert joke explanation): https://gfycat.com/queasygrandiriomotecat Neither cached data nor Merkle tree certificates reduce round-trips
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
Because that’s what CNSA requires. Regards, Uri > On Mar 29, 2023, at 00:45, Kampanakis, Panos wrote: > > > > > I would also like secp384r1_kyber1024 option, please. > > Why do you up the ECDH curve sec level with Kyber1024? It adds unnecessary > size to the keyshare. like secp384r1_kyber768 combines two equivalent > security levels. > Those that want to be extra conservative can go secp521r1_kyber1024 which > won’t be much worse than secp384r1_kyber1024 in performance or size. > > > > From: TLS On Behalf Of Blumenthal, Uri - 0553 - MITLL > Sent: Tuesday, March 28, 2023 10:40 PM > To: Krzysztof Kwiatkowski ; Christopher Wood > > Cc: TLS@ietf.org > Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for > draft-ietf-tls-hybrid-design > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > Can we add secp256r1_kyber768 option for those who prefer NIST curves? > > I support this. > > I would also like secp384r1_kyber1024 option, please. > > Thanks smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Proposal to make TLS universal
Dear TLS Working Group, Thank you for your response to our previous message from Eric Rescorla. We appreciate your clarification on the use of ECDH ephemeral for encrypting the exchange of certificates in the TLS 1.3 handshake. Based on this information, we have a new proposal to make TLS universal and promote the use of encryption across the internet. Our idea is to use ECDH ephemeral to create secure connections for sites that do not have certificates. This will provide a low level of security for these sites, but still better than the current situation where plaintext HTTP is used for these sites. Furthermore, using a certificate for a site should provide a medium level of security, which is already the case. Finally, mutual authentication should provide a high level of security. We believe this approach would be in line with the spirit of the Browser Forum, which seeks to promote universal encryption on the internet. Furthermore, our proposal to use ECDHE for securing connections without a certificate provides the same level of assurance as the use of low-assurance certificates, such as those issued by Let's Encrypt or Cloudflare, which do not guarantee the identity of the server and its owners. In fact, many certificates simply guarantee that the site is hosted by a particular provider, such as the certificate used any site on Cloudflare, which lists Cloudflare, Inc. as the organization. Our proposal offers a more universal approach to encryption that doesn't rely on specific certificate authorities or their levels of assurance, and it would bring the benefits of encryption to all sites, regardless of their level of technical sophistication or resources. Additionally, it is worth noting that many websites currently use low-assurance certificates simply to meet TLS requirements and enable encryption on their channels. This practice goes against the original philosophy of TLS, which was designed to provide strong assurance of server identity. Therefore, our proposal to include a low-assurance level using ephemeral ECDH in TLS would not only make the protocol universal but also help mitigate this problem. This reinforces the idea of including a method within TLS for users to securely utilize the protocol without having to resort to workarounds. We believe that by making encryption available to all sites, we can promote greater security on the internet. This proposal will also help users understand the level of security provided by their connections and will encourage them to demand stronger security where it is necessary. Thank you for your consideration, and we look forward to your response. Best regards, Yannick LaRue SSE Carte à Puce Inc. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposal to make TLS universal
Why are you calling Let's Encrypt low-assurance? The ACME protocol verifies that the requester of the certificate controls the domain. Honestly, I don't understand the problem you're trying to solve. Obtaining a TLS certificate is not a hurdle any more nowadays, as it can trivially be done automatically using ACME. Some web servers (like Caddy) even do it for you on the fly, making it trivial to set up a server with a proper TLS configuration. On Thu, 30 Mar 2023 at 10:07, Yannick LaRue wrote: > Dear TLS Working Group, > > > > Thank you for your response to our previous message from Eric Rescorla. We > appreciate your clarification on the use of ECDH ephemeral for encrypting > the exchange of certificates in the TLS 1.3 handshake. > > > > Based on this information, we have a new proposal to make TLS universal > and promote the use of encryption across the internet. Our idea is to use > ECDH ephemeral to create secure connections for sites that do not have > certificates. This will provide a low level of security for these sites, > but still better than the current situation where plaintext HTTP is used > for these sites. Furthermore, using a certificate for a site should provide > a medium level of security, which is already the case. Finally, mutual > authentication should provide a high level of security. We believe this > approach would be in line with the spirit of the Browser Forum, which seeks > to promote universal encryption on the internet. > > > > Furthermore, our proposal to use ECDHE for securing connections without a > certificate provides the same level of assurance as the use of > low-assurance certificates, such as those issued by Let's Encrypt or > Cloudflare, which do not guarantee the identity of the server and its > owners. In fact, many certificates simply guarantee that the site is hosted > by a particular provider, such as the certificate used any site on > Cloudflare, which lists Cloudflare, Inc. as the organization. Our proposal > offers a more universal approach to encryption that doesn't rely on > specific certificate authorities or their levels of assurance, and it would > bring the benefits of encryption to all sites, regardless of their level of > technical sophistication or resources. > > > > Additionally, it is worth noting that many websites currently use > low-assurance certificates simply to meet TLS requirements and enable > encryption on their channels. This practice goes against the original > philosophy of TLS, which was designed to provide strong assurance of server > identity. Therefore, our proposal to include a low-assurance level using > ephemeral ECDH in TLS would not only make the protocol universal but also > help mitigate this problem. This reinforces the idea of including a method > within TLS for users to securely utilize the protocol without having to > resort to workarounds. > > > > We believe that by making encryption available to all sites, we can > promote greater security on the internet. This proposal will also help > users understand the level of security provided by their connections and > will encourage them to demand stronger security where it is necessary. > > > > Thank you for your consideration, and we look forward to your response. > > > > Best regards, > > > > Yannick LaRue > > SSE Carte à Puce Inc. > ___ > 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] Proposal to make TLS universal
I wish people would stop citing the Cloudflare example as if something nefarious is going on there. It is absolutely, 100% false that the identity in a certificate should identify who Cloudflare is getting the certificate on behalf of. Cloudflare requests the certificates, holds the keys, and operates the servers. It is the correct entity to identify as the certificate subject. Modern web architectures are complicated, and there are other organizations participating in other roles. It would be possible to name those as well, but you'd have to define the roles, what they mean, how to validate them, and how to put them into certificates. If people want to make proposals in that area, they certainly can. But Cloudflare isn't doing anything wrong here. -Tim From: TLS On Behalf Of Yannick LaRue Sent: Tuesday, March 28, 2023 12:29 AM To: tls@ietf.org Subject: [TLS] Proposal to make TLS universal Dear TLS Working Group, Thank you for your response to our previous message from Eric Rescorla. We appreciate your clarification on the use of ECDH ephemeral for encrypting the exchange of certificates in the TLS 1.3 handshake. Based on this information, we have a new proposal to make TLS universal and promote the use of encryption across the internet. Our idea is to use ECDH ephemeral to create secure connections for sites that do not have certificates. This will provide a low level of security for these sites, but still better than the current situation where plaintext HTTP is used for these sites. Furthermore, using a certificate for a site should provide a medium level of security, which is already the case. Finally, mutual authentication should provide a high level of security. We believe this approach would be in line with the spirit of the Browser Forum, which seeks to promote universal encryption on the internet. Furthermore, our proposal to use ECDHE for securing connections without a certificate provides the same level of assurance as the use of low-assurance certificates, such as those issued by Let's Encrypt or Cloudflare, which do not guarantee the identity of the server and its owners. In fact, many certificates simply guarantee that the site is hosted by a particular provider, such as the certificate used any site on Cloudflare, which lists Cloudflare, Inc. as the organization. Our proposal offers a more universal approach to encryption that doesn't rely on specific certificate authorities or their levels of assurance, and it would bring the benefits of encryption to all sites, regardless of their level of technical sophistication or resources. Additionally, it is worth noting that many websites currently use low-assurance certificates simply to meet TLS requirements and enable encryption on their channels. This practice goes against the original philosophy of TLS, which was designed to provide strong assurance of server identity. Therefore, our proposal to include a low-assurance level using ephemeral ECDH in TLS would not only make the protocol universal but also help mitigate this problem. This reinforces the idea of including a method within TLS for users to securely utilize the protocol without having to resort to workarounds. We believe that by making encryption available to all sites, we can promote greater security on the internet. This proposal will also help users understand the level of security provided by their connections and will encourage them to demand stronger security where it is necessary. Thank you for your consideration, and we look forward to your response. Best regards, Yannick LaRue SSE Carte à Puce Inc. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis
https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07 might be helpful to others. I opened a few issues, but the TLS 1.3 revision is very much ready to be published. For the 8447 revision, I found that our decision to remove the definition of the fields for each registry to be difficult. The draft lists changes, so now this document is no longer an easy reference for how to register TLS extension bits. Not a big deal and I don't want to ask the authors to flip flop here, but I wanted to flag it. On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote: > As mentioned during yesterday's meeting, this email starts the working > group last call for "The Transport Layer Security (TLS) Protocol > Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located > here: > > - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis > - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis > > The WG Last Call will end on April 18, 2023. > > Please review the documents and submit issues or pull requests via the > GitHub repositories, which can be found at: > > - https://github.com/tlswg/tls13-spec > - https://github.com/tlswg/rfc8447bis > > Alternatively, you can also send your comments to tls@ietf.org. > > Thanks, > Chris > ___ > 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] TLS 1.2 deprecation
Hi, I watched the conversation at the end of this conference here: https://youtu.be/u_sFyz4F7dc It was good. The only thing I would add is that I think client authentication is already much different in 1.3, and that new extensions such as ECH are already not being done for 1.2. The thing to do if you have a strong opinion is to not serve 1.2 traffic. The clients will always have to be accepting for a while. But, if you've worked on the internet for any amount of time, you'll quickly figure out that not serving 1.2 will save you money, unless you are Google scale. Not because it is way slower, but because you can drop old clients. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 deprecation
It was good. The only thing I would add is that I think client authentication is already much different in 1.3, and that new extensions such as ECH are already not being done for 1.2. Do you think discussion of client auth should be described in the draft? Yes, new work is not being done for 1.2, but we are also talking about explicitly stating that the registries will not (not 2119 notation on purpose) accept new algorithms, etc., for 1.2. You might also find the Zulip chat[1] and minutes [2] useful. [1] https://zulip.ietf.org/#narrow/stream/140-tls/topic/ietf-116 [2] https://notes.ietf.org/notes-ietf-116-tls#TLS-12-Deprecation ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
On Wed, Mar 29, 2023 at 10:48:32AM +0900, Christopher Wood wrote: > As discussed during yesterday's meeting, we would like to assess > consensus for moving draft-ietf-tls-hybrid-design forward with the > following strategy for allocating codepoints we can use in > deployments. > > 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance >this document through the process towards publication. Support. > 2. Write a simple -00 draft that specifies the target variant of > X25519+Kyber768 with a codepoint from the standard ranges. (Bas > helpfully did this for us already [1].) Once this is complete, > request a codepoint from IANA using the standard procedure. I have a concern with this: The draft draft-tls-westerbaan-xyber768d00-00 references draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, since fixed in editor's copy. And then, the correct reference for X25519 is probably RFC7748 instead of RFC8037... Really quick and dirty way to fix this would be to publish editor's copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing the references. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
On Wed, Mar 29, 2023 at 02:59:51PM +, Blumenthal, Uri - 0553 - MITLL wrote: > Because that’s what CNSA requires. I don't think that is the case. CNSA1 does not consider the Kyber part, and CNSA2 requires something that is not currently available. > > On Mar 29, 2023, at 00:45, Kampanakis, Panos wrote: > > > > > > > > > I would also like secp384r1_kyber1024 option, please. > > > > Why do you up the ECDH curve sec level with Kyber1024? It adds > > unnecessary size to the keyshare. like secp384r1_kyber768 > > combines two equivalent security levels. Is that the case? Secp384r1 is 192-level DH, but Kyber768 is quoted to be Category III (and I think it is not significantly above Category III requirements), which is defined as equivalent to 192-level encryption. 192-level DH is stronger than 192-bit encryption. (Another illustration of numbers not being comparable is that Category IV is defined as equivalent to 192-level hash.) I would pair secp384r1 with Kyber768 for completely different reasons: Kyber768 is what the team kyber recommends. > > From: TLS On Behalf Of Blumenthal, Uri - 0553 - MITLL > > Sent: Tuesday, March 28, 2023 10:40 PM > > To: Krzysztof Kwiatkowski ; Christopher Wood > > > > Cc: TLS@ietf.org > > Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for > > draft-ietf-tls-hybrid-design > > > > Can we add secp256r1_kyber768 option for those who prefer NIST > > curves? > > > > I support this. > > > > I would also like secp384r1_kyber1024 option, please. > > > > Thanks I don't think there are very good reasons for NIST curves here outside wanting CNSA1 compliance, and for that you need secp384r1 classical part. And for that, I would pick secp384r1_kyber768. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
