>From the server operator side, I feel strongly that the multi-CDN example
should show a selected CDN setup not a merged CDN setup.
The "Automation is required to keep these records consistent with the
original records in the CDN providers' zones." mentioned
in the current example is outside of the
OK. Erik, Mike, Paul: Let me know if you have any further comments on #18.
--Ben
From: Sean Turner
Sent: Wednesday, October 16, 2024 3:06 PM
To: draft-ietf-tls-svcb-ech.auth...@ietf.org
Cc: dn...@ietf.org WG ; TLS List
Subject: Re: [TLS] [DNSOP] Re: Re: Re: Re
Authors (Ben, Mike, and Eric),
Thank for the PR with some examples:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18
Once you’ve settled the debate (hopefully before Monday), please go ahead and
merge so that Paul can get the IETF LC started.
Cheers,
spot
> On Oct 9, 2024, at 09:38, Se
Authors (Ben, Mike, and Eric),
It looks like we haves some agreement here. There’s some agreement that the PR
[1] addresses the concern and there’s some agreement to agree to disagree on
other points. Please go ahead and merge the PR [1].
spt
[1] https://github.com/tlswg/draft-ietf-tls-svcb-e
I agree that you can't trust a resolver that you only know about from ADD.
-Ekr
On Tue, Oct 8, 2024 at 8:31 AM Paul Wouters wrote:
> I agree with your points. Our only difference of opinion seems to be about
> how much one should trust a TRR.
> I still prefer to need to trust them the least po
I agree with your points. Our only difference of opinion seems to be about
how much one should trust a TRR.
I still prefer to need to trust them the least possible, meaning I would
want DNSSEC validation to at least
detect tampering at the TRR. With more ECH deployed, and less visibility of
SNI, th
Paul,
I don't understand your threat model here.
1. As already noted upthread, ECH inherently leaks the name you are
resolving to the resolver. This leak doesn't depend on the resolver
tampering with the response, so DNSSEC verification on the client
doesn't help here [0].
2. If the client accep
On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
>>
>> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>>
>>> This is explicitly prohibited rfc9460 as it would provide linkability.
> See rfc9460 section 12: "Clients MUST ens
On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>
>> This is explicitly prohibited rfc9460 as it would provide linkability.
See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
partitioned for each local networ
On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
>>> partitioned for each local network, or flushed on network changes, to
>>> prevent a local adve
On Sun, Oct 6, 2024 at 9:09 AM Paul Wouters wrote:
> [kind of off-topic here, and also speaking as just an individual]
>
> On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote:
>
>>
>> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
>> wrote:
>>
>>>
>>> On 10/4/24 19:30, Paul Wouters wrote:
>>> > Wh
[kind of off-topic here, and also speaking as just an individual]
On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote:
>
> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
> wrote:
>
>>
>> On 10/4/24 19:30, Paul Wouters wrote:
>> > Which makes me wonder if it makes sense to advise long TTLs on these
If appropriate, we could pick up this issue in our ECH Deployment
Considerations draft. Happy to discuss in Dublin if there is interest in
adding to our existing text.
Andrew
On 4 Oct 2024, at 19:39, Salz, Rich wrote:
* I would not be in favor of this. This is been intensely controver
Hi Erik,
Agree it is out of the scope of this draft, but we have another vehicle that
would be ideal to capture what you write
We didn’t push it too much in the past 9+ months as per agreement with ADs and
Working Group chairs, Eric and others to wait for ECH to be ratified first and
on our
On Fri, Oct 4, 2024 at 3:48 PM Salz, Rich wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>
>
>
> So what? We’re not the protocol police and if someone wants to track,
> RFC9460 compliance isn’t going to stop them. Especially for something as
> controversial as EC
On Fri, Oct 4, 2024 at 11:32 AM Paul Wouters
wrote:
>
>
> On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz wrote:
>>
>> I've updated PR#16 to reframe this paragraph as a statement of fact:
>> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files
>
>
> Speaking as individual,
>
>>
>>
>> It s
This is explicitly prohibited rfc9460 as it would provide linkability.
So what? We’re not the protocol police and if someone wants to track, RFC9460
compliance isn’t going to stop them. Especially for something as controversial
as ECH.
___
TLS mailin
On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
wrote:
>
> On 10/4/24 19:30, Paul Wouters wrote:
> > Which makes me wonder if it makes sense to advise long TTLs on these
> > records so that they move along on your phone/laptop even if you enter
> > these kind of networks.
>
> There's a tension bet
Hiya,
On 10/4/24 19:30, Paul Wouters wrote:
Which makes me wonder if it makes sense to advise long TTLs on these
records so that they move along on your phone/laptop even if you enter
these kind of networks.
There's a tension between that and getting better forward-secrecy
by rotating ECH key
Yeah, I have to agree with Ekr and Rich here. However, if the issues are so
widespread to make a deal breaker as some say, that will inhibit adoption.
After all, the IETF can't make people use ECH, and it's easy enough to
strip the ECH extension at the cost of interoperability. Obviously, the WG
th
It might make sense to expand on this to:
> ECH ensures that TLS does not disclose the SNI, but the same information
is also present in the DNS queries used to resolve the server's hostname.
This specification does not conceal the server name from the DNS resolver.
If DNS messages are sent between
The suggested text seems inoffensive to me as well, but we may also want to
expand it to cover the recursive-to-authoritative path for resolvers
associated with the client. (ie, just using DoH to your home router isn't
going to help when it uses Do53 to the authorities.).
On the topic of DNSSEC,
* I would not be in favor of this. This is been intensely controversial and
I want the document done
I agree. The PR acknowledges the issue and that’s enough in my view. Any
additional work on how to deploy something in DNS will require close
coordination with the DNS folks and add an inte
On Fri, Oct 4, 2024 at 11:30 AM Paul Wouters wrote:
>
> On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz wrote:
>
>> I've updated PR#16 to reframe this paragraph as a statement of fact:
>> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files
>>
>
> Speaking as individual,
>
>
>>
>> It seem
On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz wrote:
> I've updated PR#16 to reframe this paragraph as a statement of fact:
> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files
>
Speaking as individual,
>
> It seems strange to me to describe a vulnerability without explaining how
>
On Fri, Oct 4, 2024 at 11:39 AM Stephen Farrell
wrote:
>
>
> On 10/4/24 16:09, Salz, Rich wrote:
> > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 "Discuss
> > the impact of resolver selection on security"
>
> That suggested text seems inoffensive to me fwiw.
>
>
Agree with Stephen, th
On 10/4/24 16:09, Salz, Rich wrote:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 "Discuss
the impact of resolver selection on security"
That suggested text seems inoffensive to me fwiw.
S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 10/4/24 15:58, Salz, Rich wrote:
> I disagree. It will show that some concerns have been heard, if not
> addressed. Comity is all to rare these days.
On 10/4/24, 11:03 AM, "Stephen Farrell" wrote:
> Sorry, what's the "it"? (Apologies if I missed some
> specific proposal that was made.)
https:
On 10/4/24 15:58, Salz, Rich wrote:
I disagree. It will show that some concerns have been heard, if not
addressed. Comity is all to rare these days.
Sorry, what's the "it"? (Apologies if I missed some
specific proposal that was made.)
Ta,
S.
OpenPGP_signature.asc
Description: OpenPGP digi
I don't really think it's helpful to re-litigate the broader topic of the
merits of ECH; nothing we say in security considerations will make a material
difference there.
I disagree. It will show that some concerns have been heard, if not addressed.
Comity is all to rare these days.
___
I've updated PR#16 to reframe this paragraph as a statement of fact:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files
It seems strange to me to describe a vulnerability without explaining how to
mitigate it, but I'm willing to move forward if this is all we have consensus
for.
--
I don't really think it's helpful to re-litigate the broader topic of the
merits of ECH; nothing we say in security considerations will make a
material difference there.
With that said, I don't love the last sentence as we know users don't
really choose their resolvers. How about simply stating th
32 matches
Mail list logo
