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, such
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 desi
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 f
> 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
>>
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 bloc
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 web.
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.
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 co
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 that
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 home
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, which
> 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 dea
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 TLS
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
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 agreeme
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 particul
> 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 rea
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 c
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?
thank
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 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 par
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 d
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 inclu
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 trad
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
> inte
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
opini
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
> necess
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.
Interesting
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 whateve
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,
30 matches
Mail list logo
