[TLS] Fwd: New Non-WG Mailing List: web-bot-auth

FYI. > Begin forwarded message: > > From: IETF Secretariat > Subject: New Non-WG Mailing List: web-bot-auth > Date: 17 March 2025 at 2:04:28 pm GMT+7 > To: "IETF Announcement List" > Cc: web-bot-a...@ietf.org, m...@mnot.net > Reply-To: i...@ietf.org > > A new IETF non-working group email list

[TLS] Re: Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard

Hi Paul, The draft already contains the following guidance to address this point on how to treat items marked as "D": "D: Indicates that the item is discouraged. This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorith

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

On Sun, Mar 16, 2025 at 7:52 PM David Benjamin wrote: > > I'd also add that, *if* we want something PAKE-shaped in a web-like > context, I don't think TLS-PAKE is a good fit for it. (Which is fine! Not > everything needs to be for every use case.) > Yes, I was thinking of mobile phone sign-in us

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

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.

[TLS] Re: A different approach to Attestation

With due respect, no this is not the same at all. They may provide the same functionality but the technical implementation is entirely different as are the security guarantees and the complexity of the TPM module operations. It appears that we have very different use cases. The notion of allowing

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

> 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

[TLS] Re: [Last-Call] Re: Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard

So, again: This draft should either be expanded to say what TLS clients and servers and configuration SHOULD / MUST do with D-level components, or tell readers why it is not. Telling developers "go look at every doc that is liked from a D-level spec" is likely to cause them to not do so, and the

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM KeyAgreement for TLSv1.3

Some relevant additional detail from NIST's paper selecting HQC.. On Thursday, 13 March 2025 10:01 UTC, Alicja Kario wrote: > NIST has selected HQC for standardisation this week... No idea about > its patent situation, or if we want something with ciphertexts this big in > TLS... (reminder: 4.4 ki

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM KeyAgreement for TLSv1.3

Hi, I think HQC is a good backup algorithm to ML-KEM for ephemeral key exchange. I would like to see HQC supported in TLS, but I would not use it unless something is wrong with ML-KEM (theoretical or implementation). If used in TLS key exchange, both the sizes of the encapsulation keys and the

[TLS] Re: Artart last call review of draft-ietf-tls-rfc8447bis-11

> On Mar 17, 2025, at 7:21 AM, Barry Leiba via Datatracker > wrote: > > Reviewer: Barry Leiba > Review result: Ready with Nits > > This document is in good shape and does what it needs to do. I have just one > very minor substantive comment, and two very nitty nits: > > — Section 3.1 — > >

[TLS] Re: Artart last call review of draft-ietf-tls-rfc8447bis-11

Perfect; thanks so much! Barry On Mon, Mar 17, 2025 at 2:46 PM Sean Turner wrote: > > On Mar 17, 2025, at 7:21 AM, Barry Leiba via Datatracker > wrote: > > Reviewer: Barry Leiba > Review result: Ready with Nits > > This document is in good shape and does what it needs to do. I have just > one

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

Hi Laura, Hi all, I plan to come up with a more detailed review of the draft this week together with description of the actual use-cases. In our company’s setting the main use-case for PAKE are customer-owned server devices that are not yet integrated in a PKI and yet not integrated with other

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

On Mon, Mar 17, 2025 at 9:22 AM Rob Sayre wrote: > > > On Mon, Mar 17, 2025 at 8:49 AM Eric Rescorla wrote: > >> >> >> On Mon, Mar 17, 2025 at 8:37 AM Rob Sayre wrote: >> >>> On Sun, Mar 16, 2025 at 7:52 PM David Benjamin >>> wrote: >>> I'd also add that, *if* we want something PAKE-

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

On Mon, Mar 17, 2025 at 8:49 AM Eric Rescorla wrote: > > > On Mon, Mar 17, 2025 at 8:37 AM Rob Sayre wrote: > >> On Sun, Mar 16, 2025 at 7:52 PM David Benjamin >> wrote: >> >>> >>> I'd also add that, *if* we want something PAKE-shaped in a web-like >>> context, I don't think TLS-PAKE is a good

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

On Mon, Mar 17, 2025 at 8:37 AM Rob Sayre wrote: > On Sun, Mar 16, 2025 at 7:52 PM David Benjamin > wrote: > >> >> I'd also add that, *if* we want something PAKE-shaped in a web-like >> context, I don't think TLS-PAKE is a good fit for it. (Which is fine! Not >> everything needs to be for every

[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

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, the