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

On Tue, Mar 25, 2025, at 02:37, Eric Rescorla wrote: > 1. Getting PQ resistance for free even with non-PQ PAKEs. > 2. Reducing the combinatoric explosion of "groups" I don't know that you are really getting PQ resistance if your PAKE remains vulnerable. You might maintain confidentiality for tha

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

On Mon, Mar 24, 2025 at 5:17 PM Martin Thomson wrote: > On Tue, Mar 25, 2025, at 02:37, Eric Rescorla wrote: > > 1. Getting PQ resistance for free even with non-PQ PAKEs. > > 2. Reducing the combinatoric explosion of "groups" > > I don't know that you are really getting PQ resistance if your PAKE

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

On Mon, Mar 24, 2025 at 8:34 AM Christopher Patton wrote: > Hi EKR, > > >> I agree we shouldn't *disable* key_share, but it seems like the right >> answer here is to instead combine the PAKE output with the existing key >> establishment. >> > > I probably just missed this in the discussion, but w

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

Hi EKR, > I agree we shouldn't *disable* key_share, but it seems like the right > answer here is to instead combine the PAKE output with the existing key > establishment. > I probably just missed this in the discussion, but what would be the advantage of combining PAKE with the existing key exch

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

I agree we shouldn't *disable* key_share, but it seems like the right answer here is to instead combine the PAKE output with the existing key establishment. -Ekr On Mon, Mar 24, 2025 at 7:56 AM Christopher Patton wrote: > I've read the draft and support doing this. However, I wanted to +1 > Ma

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

I've read the draft and support doing this. However, I wanted to +1 Martin's suggestion of restricting this to 2-move PAKEs (1 round trip) if possible, and if so, defining a new key_share rather than a new extension that disables key_share. It seems like this would be a much simpler design. Chris

[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

[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: 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

[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: 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 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

ract offer unless explicitly and conspicuously designated or stated as such. Von: Eric Rescorla Gesendet: Montag, 17. März 2025 00:16 An: Rob Sayre Cc: Laura Bauman ; tls@ietf.org Betreff: [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre mailto

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

On Mon, Mar 17, 2025 at 6:17 AM Eric Rescorla wrote: > On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre wrote: > >> On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman > 40apple@dmarc.ietf.org> wrote: >> >>> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt >>> and provided feedback

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

On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre wrote: > On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman 40apple@dmarc.ietf.org> wrote: > >> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt >> and provided feedback so far. As more people start reading it, I wanted to >> clarif

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

On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman wrote: > Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt > and provided feedback so far. As more people start reading it, I wanted to > clarify that the current draft version does not yet reflect the change we > intend to make t