[TLS] I-D Action: draft-ietf-tls-ecdhe-mlkem-00.txt
Internet-Draft draft-ietf-tls-ecdhe-mlkem-00.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 Authors: Kris Kwiatkowski Panos Kampanakis Bas Westerbaan Douglas Stebila Name:draft-ietf-tls-ecdhe-mlkem-00.txt Pages: 9 Dates: 2025-03-23 Abstract: This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-esni (+0/-1/đź’¬0) 1 issues closed: - Meaning of "authenticated" in name validation section https://github.com/tlswg/draft-ietf-tls-esni/issues/643 [pr available] * tlswg/rfc8447bis (+1/-2/đź’¬0) 1 issues created: - Address ArtArt review comments (by seanturner) https://github.com/tlswg/rfc8447bis/issues/71 2 issues closed: - Address ArtArt review comments https://github.com/tlswg/rfc8447bis/issues/71 - Address ArtArt review comments https://github.com/tlswg/rfc8447bis/issues/71 Pull requests - * tlswg/draft-ietf-tls-esni (+6/-5/đź’¬1) 6 pull requests submitted: - Update DNS-related security considerations text (by bemasc) https://github.com/tlswg/draft-ietf-tls-esni/pull/649 - Address ARTART review (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/648 - Fix cache (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/647 - DNS directorate review comments (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/646 - This addresses the issues in Stewart Bryant's review. (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/645 - Remove extra confusing sentence. Fixes #643 (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/644 1 pull requests received 1 new comments: - #644 Remove extra confusing sentence. Fixes #643 (1 by bemasc) https://github.com/tlswg/draft-ietf-tls-esni/pull/644 5 pull requests merged: - DNS directorate review comments https://github.com/tlswg/draft-ietf-tls-esni/pull/646 - This addresses the issues in Stewart Bryant's review. https://github.com/tlswg/draft-ietf-tls-esni/pull/645 - Address ARTART review https://github.com/tlswg/draft-ietf-tls-esni/pull/648 - Remove extra confusing sentence. Fixes #643 https://github.com/tlswg/draft-ietf-tls-esni/pull/644 - Fix cache https://github.com/tlswg/draft-ietf-tls-esni/pull/647 * tlswg/rfc8447bis (+2/-2/đź’¬0) 2 pull requests submitted: - Address SecDir comments (by seanturner) https://github.com/tlswg/rfc8447bis/pull/73 - Fit Nits from ArtArt Review (by seanturner) https://github.com/tlswg/rfc8447bis/pull/72 2 pull requests merged: - Fix Nits from ArtArt Review https://github.com/tlswg/rfc8447bis/pull/72 - Fix nits from SecDir Review https://github.com/tlswg/rfc8447bis/pull/70 * tlswg/tls-key-update (+1/-0/đź’¬0) 1 pull requests submitted: - Fix typo for Post Quantum cryptography (by loganaden) https://github.com/tlswg/tls-key-update/pull/18 Repositories tracked by this digest: --- * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/dnssec-chain-extension * https://github.com/tlswg/draft-deprecate-obsolete-kex * https://github.com/tlswg/draft-ietf-tls-cert-abridge * https://github.com/tlswg/draft-ietf-tls-ctls * https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead * https://github.com/tlswg/draft-ietf-tls-ech-keylogfile * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-grease * https://github.com/tlswg/draft-ietf-tls-iana-registry-updates * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-svcb-ech * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/draft-ietf-tls-tls13-vectors * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/dtls-rrc * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/rfc4492bis * https://github.com/tlswg/rfc8447bis * https://github.com/tlswg/rfc8773bis * https://github.com/tlswg/sniencryption * https://github.com/tlswg/sslkeylogfile * https://github.com/tlswg/sslv3-diediedie * https://github.com/tlswg/super-jumbo-record-limit * https://github.com/tlswg/tls13-spec * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/tls-flags * https://github.com/tlswg/tls-key-share-prediction * https://github.com/tlswg/tls-key-update * https://github.com/tlswg/tls-record-limit * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/tls12-frozen * https://github.com/tlswg/tls13-pkcs1 * https://github.com/tlswg/tls13-rfc -- To have a summary like this sent to your list, see: https://github.com/ietf-github-services/activity-summary ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
Hi, I watched the meeting on YouTube. It seems like it went pretty well. SSL/TLS has improved over the years. We don't advise use of SSL3 or TLS 1.0 anymore. PAKEs are the same. They get better. The comments along the lines of "have the chairs checked" or "run up against the PAKE wall" or "we've tried this before" are indirect. The problem with these PAKE ideas is that they work. What everyone fears will happen is that the draft will go all the way through the process, only to be met by an IPR disclosure. It will be something like "Northcom Telstar Logistics Business Company". That is just the government using a chilling effect. Maybe it is different this time around, but I am not optimistic. thanks, Rob On Mon, Mar 17, 2025 at 7:23 PM Laura Bauman wrote: > > On Mar 18, 2025, at 1:44 AM, Rob Sayre wrote: > > On Mon, Mar 17, 2025 at 10:02 AM Rob Sayre wrote: > >> On Mon, Mar 17, 2025 at 9:38 AM Eric Rescorla wrote: >> >>> >>> As above, I don't see what this has to do with PAKEs at all. If you have >>> a third >>> party authentication system, whether sign in with Apple, Google, or some >>> SSO >>> provider, then you don't need to share any secret with the relying party. >>> >> >> In my mind, the idea is that you don't have to rely solely on WebPKI if >> you have that information handy after registration. >> > > The other PAKE draft on the agenda explains this motivation better in its > introduction, although the mechanism is different: > > > https://www.ietf.org/archive/id/draft-guo-pake-pha-tls-01.html#name-introduction > > In draft-bmw-tls-pake13-01, the words "such as" are doing a lot of work in > the abstract and introduction. I doubt they are aiming at passwords that a > user types, given all of their other efforts to ditch passwords, but idk. > > > Our usage of “password” in the abstract/introduction appears to be a bit > misleading. There is a disconnect between the term password (as in > P(assword)AKE) and what we view as the motivating use cases for this > mechanism, namely: > > 1. One time connections with no need for a long term authentication > credentials (e.g. screen casting, video conferencing equipment) > 2. An initial connection over which high entropy long term credentials > (e.g. external PSK, RPKs) can be exchanged (e.g. pairing, device setup) > > In these cases, the “password” is more likely to be a passcode/pin or > otherwise temporary low entropy secret. We are not aiming to provide a > solution or alternative for web login use cases or advocating for users to > need to enter passwords more places. > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
