Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension
Hi Rory, I echo Watson and Martin, lets discuss this in the HTTP WG. As for a very brief technical response. In general I'm supportive of the idea of more agility of the static table but I think my motivations would be different than the ones behind this proposal. For me, I'd like more domain-specific tables to be defined, and to have the possibility of asymmetric tables; but lets stick that on the side for now. The QPACK static table description states "The order of the entries is optimized to encode the most common header fields with the smallest number of bytes.". How does the proposed append-only table gel with this? I.e. each year, the new most common fields are added to the end? At what point would it make sense to wipe out the cruft and define a newer table altogether? I think what might be needed is a good amount of datamodelling and simulation that is sufficient to decide when there is activation energy to make changes. Perhaps the proposal is a compromise to make it low effort enough for implementations to update, that they don't need tremendous amounts of overwhelming evidence to keep up. IIRC historically the effort to sample the Internet and propose a table has been quite high, and there have been some criticisms about the outputs. Given the HTTP WG has struggled with this aspect, I think it is decidedly impractical to make IANA or a designated expert solely responsible for deciding the QPACK entries. This is something that has to run through a consensus approach IMO, especially as lower entries are more valuable and couldn't ever be reclaimed. I think the largest activation energy would be to convince endpoints to implement the negotiation mechanism because it is pushing it into the TLS layer and that crosses implementation boundaries. Watson asks why not SETTINGS. One answer is that it requires clients to have to wait for the server's settings, which adds a delay that many clients don't already apply. Trading off latency for a few bytes doesn't sound like a good tradeoff. Indeed, this is why we optimised the static table for the clien'ts first flight before it knows if the server supports dynamic QPACK or not. Putting a client's static QPACK preference in a Client Hello is a fingerprinting vector, so that is a concern. Perhaps a middleground is to use a SETTING but then rope in the old ALPS proprosal [1] so that the client learns the server's view as early as required, and the client sends its view in SETTINGS after protection is established. Changing track a bit, I don't understand why your proposal requires the client and server to agree on the extension value. Its a declaration of what the endpoint can support and I don't think there is any issue in e.g. the client being willing to receive references to entries greater than 99 and the server refusing to. Encoding asymmetry is already part of QPACK DNA. Cheers, Lucas [1] - https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps On Wed, Sep 27, 2023 at 1:40 AM Martin Thomson wrote: > On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote: > > Apologies if I should respond directly to the mailing list - my old W3C > > profile has disappeared and I'm trying to get it back... > > Just on this point. Watson added the HTTP working group, which I think is > the right thing to do here. The maintenance of HTTP/3 now formally belongs > in that group. The work of defining a TLS extension for that purpose would > occur there (if indeed a TLS extension is the right choice, as Watson asks). > > As for the W3C involvement, the HTTP working group is an IETF activity > that - for historical reasons - uses a W3C-hosted mailing list. You don't > need to be a W3C member to sign up for that list. The process is just a > little different than for other IETF lists. See > https://lists.w3.org/Archives/Public/ietf-http-wg/ for details. > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension
On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote: > Apologies if I should respond directly to the mailing list - my old W3C > profile has disappeared and I'm trying to get it back... Just on this point. Watson added the HTTP working group, which I think is the right thing to do here. The maintenance of HTTP/3 now formally belongs in that group. The work of defining a TLS extension for that purpose would occur there (if indeed a TLS extension is the right choice, as Watson asks). As for the W3C involvement, the HTTP working group is an IETF activity that - for historical reasons - uses a W3C-hosted mailing list. You don't need to be a W3C member to sign up for that list. The process is just a little different than for other IETF lists. See https://lists.w3.org/Archives/Public/ietf-http-wg/ for details. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-svcb-ech-00.txt
Internet-Draft draft-ietf-tls-svcb-ech-00.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings Authors: Ben Schwartz Mike Bishop Erik Nygren Name:draft-ietf-tls-svcb-ech-00.txt Pages: 6 Dates: 2023-09-26 Abstract: To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] New approach to timing attacks against RSA key exchange - the Marvin Attack
Hello, Today we made public the new approach for attacking RSA key exchange in TLS, and RSA based encryption in general (many multiple bugs we discovered were caused by side channels in numerical library, which makes OAEP implementations also vulnerable). As usual, the recommendation is not to use PKCS#1 v1.5 padding. All the details can be found on the vulnerability page: https://people.redhat.com/~hkario/marvin/ -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Hi all, A while back, we discussed using a DNS hint to predict key shares and reduce HelloRetryRequest, but this was dropped due to downgrade issues. In thinking through post-quantum KEMs and the various transitions we'll have in the future, I realized we actually need to address those downgrade issues now. I've published a draft below which is my attempt at resolving this. We don't need a DNS hint for the *current* PQ transition—most TLS ecosystems should stick to the one preferred option, and then clients can predict that one and move on. However, I think we need to lay the groundwork for it now. If today's round of PQ supported groups cannot be marked "prediction-safe" (see document for what I mean by that), transitioning to the *next* PQ KEM (e.g. if someone someday comes up with a smaller one that we're still confident in!) will be extremely difficult without introducing downgrades. Thoughts? David -- Forwarded message - From: Date: Mon, Sep 25, 2023 at 6:56 PM Subject: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt To: David Benjamin A new version of Internet-Draft draft-davidben-tls-key-share-prediction-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-key-share-prediction Revision: 00 Title:TLS Key Share Prediction Date: 2023-09-25 Group:Individual Submission Pages:11 URL: https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt Status: https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ HTML: https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction Abstract: This document clarifies an ambiguity in the TLS 1.3 key share selection, to avoid a downgrade when server assumptions do not match client behavior. It additionally defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension
Hey Watson, Apologies if I should respond directly to the mailing list - my old W3C profile has disappeared and I'm trying to get it back... If the consensus is that the SETTINGS frame is the best place for it, that's fine. Initially I decided on a new TLS extension because it seemed simpler and I didn't want to mess with SETTINGS. I agree that it will require both a new registry and updating it will probably be under the purview of the HTTP WG - as you say, a once-in-a-while RFC or similar. Note that the original QPACK header analysis was done in 2018 - that's 5 (almost 6!) years ago - a lifetime in the world of the internet. If I were to do similar analysis today, it would be clear that there are some very common headers in use which barely existed back then - for example, all the Client Hints headers. Primarily this isn't about specific headers - it's about future proofing. If *something* isn't implemented, then we're at risk either of companies coming up with their own QPACK static tables (which only work with *their* client devices/servers) or a sub-performant scenario where common headers are relegated to the QPACK dynamic table. Thanks, Rory -Original Message- From: Watson Ladd Sent: Monday, September 25, 2023 10:08 PM To: Hewitt, Rory Cc: HTTP Working Group ; TLS List ; Bishop, Mike Subject: Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension On Mon, Sep 25, 2023, 2:44 PM Hewitt, Rory wrote: > > Dear HTTP-BIS & TLS folks, > I would appreciate any comments, positive or negative. Rory, Great to see someone new jump in and the text is pretty clear. I do have one question: why not use the SETTINGS frame? This seems like it would fit there. Also I think IANA isn't equipped to perform that analysis, but it's something the HTTP WG could do and periodically publish a very boring RFC for, or maybe even abuse expert review in the IANA process to get the changes done. I do think something like this is worthwhile in principle, but I wouldn't be surprised if the analysis comes back "HTTP usages haven't changed enough" for a bit. Sincerely, Watson Ladd ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-03.txt
Thanks! Both points sound good to me. I pushed these changes to the main branch, I guess we'll wait to accumulate more (hopefully small) changes before publishing a new version. thanks, Nimrod On Thu, 21 Sept 2023 at 18:24, Thomas Fossati wrote: > Hi, > > Maybe I am completely confused but It also looks like the "SHOULD NOT > non-ephemeral ECDH" (second para of §2) is already in the "general > guidelines" of RFC9325. > > If you want to reiterate the point (which is good), you could just > reference it? > > cheers, t > > On Thu, 21 Sept 2023 at 17:13, Thomas Fossati > wrote: > > > > Hi, > > > > It looks like the requirements in §2 and §3 regarding FFDH(E) update > > the guidance given in RFC9325 (i.e., SHOULD NOT => MUST NOT). > > > > I guess this must be reflected in the "Updates" header. > > > > cheers, thanks > > t > > > > On Thu, 21 Sept 2023 at 10:22, wrote: > > > > > > Internet-Draft draft-ietf-tls-deprecate-obsolete-kex-03.txt is now > available. > > > It is a work item of the Transport Layer Security (TLS) WG of the IETF. > > > > > >Title: Deprecating Obsolete Key Exchange Methods in TLS 1.2 > > >Authors: Carrick Bartle > > > Nimrod Aviram > > >Name:draft-ietf-tls-deprecate-obsolete-kex-03.txt > > >Pages: 20 > > >Dates: 2023-09-21 > > > > > > Abstract: > > > > > >This document deprecates the use of RSA key exchange and Diffie > > >Hellman over a finite field in TLS 1.2, and discourages the use of > > >static elliptic curve Diffie Hellman cipher suites. > > > > > >Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 > and > > >1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the > > >affected algorithm or does not share the relevant configuration > > >options. > > > > > > The IETF datatracker status page for this Internet-Draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ > > > > > > There is also an HTML version available at: > > > > https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-03.html > > > > > > A diff from the previous version is available at: > > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-03 > > > > > > Internet-Drafts are also available by rsync at: > > > rsync.ietf.org::internet-drafts > > > > > > > > > ___ > > > 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
