On 3/14/24 11:38, Raghu Saxena wrote:
I think this is a feasible workaround.
Actually I think it is almost better, since I can "fool" naive censors
etc. into thinking users of my website are visiting "google.com" or
something, since as a server operator I control the public_name.
Regards,
On 3/14/24 00:45, Eric Rescorla wrote:
There are two questions here:
1. What the specification says
2. What implementations choose to do within the envelope of that
specification.
The specification needs to prescribe a set of behaviors that promote
interoperability, which means that
I think we are getting distracted from the point which is to consider the whole
connection time when assessing handshake impact. Even an extra RTT due to
initcwnd=10 becomes less and less significant when we are talking about 5+ RTTs
to establish the conn and transfer >50KB of data.
Thank you very much for the notes!
A few specific comments:
> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
> would suggest that the second sentence ("Having a fully post-quantum...")
> is not needed, i.e. that there need not be a justification for why it is
>
Oh and one more consideration: hybrid brings complexity, and presenting the
pure-PQ solutions and their strictly lesser complexity (at the tradeoff of
maybe taking more risk against newer schemes no matter how good we feel
about their fundamental cryptographic foundations) is worthwhile in my
Hi, Eric,
> On Mar 14, 2024, at 00:45, Eric Rescorla wrote:
>
> There are two questions here:
>
> 1. What the specification says
> 2. What implementations choose to do within the envelope of that
> specification.
>
> The specification needs to prescribe a set of behaviors that promote
>
Some considerations for ML-KEM alone (or another trusted PQ-only key
agreement) are mainly looking towards the desired next step after hybrid
key agreement, and instead of leaving that fuzzy and far off, talking about
it in the present. This is also motivated by -hybrid-design allowing
several
Agreed with ekr.
On Wed, Mar 13, 2024 at 6:27 PM Eric Rescorla wrote:
>
>
> On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> Also, what are the WG's thoughts on including standalone PQC signatures
>> in the same draft?
>>
>>
>>
>> I think that
Please, let us not assume every website is behind a CDN.
Isn't that assumption reasonable? At least for global websites --- without CDN
performance sucks.
Of course it isn’t.
As a reference point:
Consider reading the New York Times in Canberra,
Well, if you have nothing better to
On Wed, Mar 13, 2024 at 4:10 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>
>
>
> I don't think there is any
Also, what are the WG's thoughts on including standalone PQC signatures in the
same draft?
I think that including standalone PQC sigs would be very desirable.
I don't think there is any particular reason to include PQC signatures in the
same draft as PQ key establishment. In TLS 1.3, key
On Wed, Mar 13, 2024 at 3:29 PM Ben Smyth wrote:
>
> As a reference point:
>
> Consider reading the New York Times in Canberra,
>
> doesn't happen without CDN
>
> #SpeedOfLightSlow
>
I thought about it this way: who does the CDN connect to, and what happens
if the traffic is personalized?
On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie wrote:
> Greetings Deirdre and TLS,
>
>
>
> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
> and I have a few
> Given that especially for the web, CDNs used much higher initcwnds,
>
> Please, let us not assume every website is behind a CDN.
>
> Isn't that assumption reasonable? At least for global websites --- without
> CDN performance sucks.
>
> *Of course* it isn’t.
>
As a reference point:
Consider
On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>
I don't think there is any
Also, what are the WG's thoughts on including standalone PQC signatures in the
same draft?
I think that including standalone PQC sigs would be very desirable.
From: TLS On Behalf Of Deirdre Connolly
Sent: Tuesday, March 5, 2024 9:15 PM
To: TLS@ietf.org
Subject: [TLS] ML-KEM key
Greetings Deirdre and TLS,
I read through draft-connolly-tls-mlkem-key-agreement-00 (and
https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
and I have a few comments. First, though, I want to say thank you for writing
this
On Wed, Mar 13, 2024 at 9:20 AM Amir Omidi wrote:
> > I don't think it's realistic for a generic client (e.g., a standard
> browser) to omit or falsify this field.
>
> Why not? From my understanding the issue that happens in this situation is
> that the website becomes less reliable for these
> I don't think it's realistic for a generic client (e.g., a standard
browser) to omit or falsify this field.
Why not? From my understanding the issue that happens in this situation is
that the website becomes less reliable for these TLS clients?
If so, let that be a problem for the client to
On Wed, Mar 13, 2024 at 8:49 AM A A wrote:
> I think we should change outer SNI randomly and periodicity (e.g 1 hours),
> if it change fast enough, censor will need to pay a price to block it,
>
This won't work because the public_name is part of the recovery mechanism
for misconfiguration,
On Wed, Mar 13, 2024 at 8:40 AM Amir Omidi wrote:
> I'd like to understand how the behavior of the latest draft will be under
> an adversarial condition.
>
> One of the things that really excited me about ESNI back in the day was
> effectively making it near impossible for countries, like my
I think we should change outer SNI randomly and periodicity (e.g 1 hours), if it change fast enough, censor will need to pay a price to block it,13.03.2024, 23:40, "Amir Omidi" :I'd like to understand how the behavior of the latest draft will be under an adversarial condition.One of the things
On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan
wrote:
Given that especially for the web, CDNs used much higher initcwnds,
Please, let us not assume every website is behind a CDN.
Isn't that assumption reasonable? At least for global websites --- without CDN
performance sucks.
Of
On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan wrote:
> Given that especially for the web, CDNs used much higher initcwnds,
>
>
> Please, let us not assume every website is behind a CDN.
>
Isn't that assumption reasonable? At least for global websites --- without
CDN performance sucks.
I'd like to understand how the behavior of the latest draft will be under
an adversarial condition.
One of the things that really excited me about ESNI back in the day was
effectively making it near impossible for countries, like my home country
Iran, from being able to effectively censor the
On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena wrote:
> On 3/13/24 14:51, Watson Ladd wrote:
>
> > I'm not sure what problem you want us to solve here. In the case of
> > server offering a single domain, an attacker can determine that
> > connections to that domain go to the server and cheaply
> Hopefully, some of the people who did the analyses will
> chime in on the WGLC though, it'd be good if they had the
> time to do that.
I am not sure this specific case was covered in our analysis, but I will confer
with our co-authors.
Best,
Karthik
>
> Cheers,
> S.
>
>> thanks,
>> Rob
Hi,
"ECH is not in itself sufficient to protect the identity of the
server. The target domain may also be visible through other
channels, such as plaintext client DNS queries or visible server IP
addresses. However, DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094]
provide mechanisms
On 3/13/24 14:51, Watson Ladd wrote:
The reason the public_name exists is so that the connections can all
have the same SNI field. Since we can't do what ESNI did, there must
be something there and it should all be the same.
Could you elaborate a bit on this? Sorry I'm unfamiliar with some
This document does a good job of documenting current practice,
and hence I support
(and my thanks to Martin for addressing an issue I communicated to him
off-list).
I think that timestamping and/or autosegmenting entries in the file format
would be a useful extension
(current implementations,
On Tue, Mar 12, 2024 at 10:20 PM Raghu Saxena wrote:
>
> Are comments restricted strictly to members of the working group? If so,
> please ignore this E-Mail.
>
> I'd previously tried to raise an issue regarding requirements of a
> public_name in the ECHConfig in the mailing list [0], and when I
I have risen similar discussion before and have tried to suggest some
solutions, but none of them got any support.
Here is the previous discuss thread, just FYI
https://mailarchive.ietf.org/arch/msg/tls/HlwYX16Y4W2BevKTpI6a81eO1JE/
> On Mar 13, 2024, at 13:20, Raghu Saxena wrote:
>
> Are
32 matches
Mail list logo
