> If I understand Martin+Jonathan's idea correctly, it is mainly about
> indistinguishability of ECH handshakes across TLS servers.
I found this idea hard to understand because, in the ECH privacy threat model,
distinct servers are always distinguishable by destination IP address. To
start, I
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
On Tue, Mar 25, 2025, at 07:31, David Benjamin wrote:
> That's a 2^-64
> probability, which was discussed here:
> https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-10.9-2
Yeah, I was thinking holistically, but the argument made there is that the
per-connection probability is
On Sun, Mar 23, 2025 at 8:59 PM Martin Thomson wrote:
> On Sun, Mar 23, 2025, at 10:20, David Benjamin wrote:
> > This case is a protocol error and should abort the handshake,
>
> Is it though? It would appear that the probability of this occurring is
> about 50% after about 4 billion ECH grease
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
Gorry Fairhurst has entered the following ballot position for
draft-ietf-tls-tls12-frozen-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
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
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
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
On Mon, Mar 24, 2025 at 12:37 AM Mohamed Boucadair via Datatracker <
nore...@ietf.org> wrote:
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-tls-tls12-frozen-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses incl
Hi all, unfortunately I wasn't able to attend the meeting this week, but I
had a chance to catch up on youtube (
https://www.youtube.com/watch?v=bQ-Bz60AppI). I wanted to add one more
point to the ECH discussion that might be helpful for moving this topic
forward.
There were three presentations ab
Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list),
Following up on this; as a designated expert for the TLS ExtensionType Values
registry, can you review the proposed registration in draft-ietf-tls-esni-23
for us? Please note that Nick Sullivan is a co-author for this draft and that
Rich
Mohamed Boucadair has entered the following ballot position for
draft-ietf-tls-tls12-frozen-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
13 matches
Mail list logo
