roups.
Thanks,
Michael
From: Rob Sayre mailto:say...@gmail.com>>
Sent: Tuesday, October 17, 2023 9:08 PM
To: David Benjamin mailto:david...@chromium.org>>
Cc: Andrei Popov
mailto:andrei.po...@microsoft.com>>;
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] [EXTERNAL] Re
what text. It is
> presented as one document right now because that was the clearest way to
> present all the changes together.
>
> If rfc8446bis is still open for substantive changes (though my impression
> was it isn't?), I don't mind putting things in there. Though we'd still
>
This is a good document and should be adopted. I have a mild preference for a
separate document because I think it is important to keep this separate from
8446 because it would require less work (at least in the doc review aspect) for
programmers to fix, and I am worried that it would “get
n
was it isn't?), I don't mind putting things in there. Though we'd still
need to expend a lot of text to define prediction-safe and
prediction-unsafe groups, precisely because we do *not* want to define
duplicate groups.
> Thanks,
> Michael
>
>
>
>
>
> *From:* Rob Sayre
&g
Sent: Friday, 27 October 2023 22:04
To: Rob Sayre; David Benjamin
Cc: tls@ietf.org
Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for
draft-davidben-tls-key-share-prediction-00.txt
Hi All,
Thank you for this interesting draft, I had a couple of quick questions.
OpenSSL has been
implies
preference for key_share first selection.
Thanks,
Michael
From: Rob Sayre
Sent: Tuesday, October 17, 2023 9:08 PM
To: David Benjamin
Cc: Andrei Popov ; tls@ietf.org
Subject: Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for
draft-davidben-tls-key-share-prediction-00.txt
On Tue, Oct 17, 2023 at 12:32 PM David Benjamin
wrote:
>
> > Server-side protection against [clients adjusting HRR predictions on
> fallback] is not effective. Especially when we have both servers that
> cannot handle large ClientHello messages and servers that have buggy HRR.
>
> I think the
Answering a few questions that have come up thus far:
> Downgrade by attacker is only possible if the client attempts insecure
fallback (e.g., offer PQ key share, connection failed, retry without PQ key
share)?
> Or am I missing some other possible downgrade attack?
A fallback is certainly one
On Mon, Oct 16, 2023 at 5:52 PM Andrei Popov
wrote:
>
>- But how are you going to detect whether there's a crappy TCP/IP
>stack or an attack? You can't.
>
> Understood. This is a general problem with insecure client-side fallbacks.
>
Sure, but I think the aim is to say that the server
Popov
Cc: David Benjamin ; tls@ietf.org
Subject: Re: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for
draft-davidben-tls-key-share-prediction-00.txt
On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov
mailto:andrei.po...@microsoft.com>> wrote:
* Where these interpretations co
On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov
wrote:
>
>- Where these interpretations conflict, the selection may be
>downgraded, potentially even under attacker influence.
>
> Downgrade by attacker is only possible if the client attempts insecure
> fallback (e.g., offer PQ key share,
that this is necessarily wrong, generally.
Cheers,
Andrei
From: TLS On Behalf Of Rob Sayre
Sent: Monday, October 16, 2023 10:52 AM
To: David Benjamin
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for
draft-davidben-tls-key-share-prediction-00.txt
On Mon, Oct 16, 2023
12 matches
Mail list logo
