On Wed, Mar 31, 2021 at 10:43 PM Christian Huitema
wrote:
> I think that's the big motivation behind DoQ. Because QUIC runs over UDP,
> it makes some things easier than TCP. In particular, I have seen (and done)
> demos of supporting 50,000 QUIC connections over a single UDP socket, which
> is
On 3/31/2021 2:15 PM, Bill Woodcock wrote:
We have that:
https://vaibhavbajpai.com/documents/papers/proceedings/dot-pam-2021.pdf
That paper is about home measurements, and says:
"Previous work [8,17,26] has studied the support and response times of
DoT (and DoH). However, the studies
> On Apr 1, 2021, at 12:32 AM, Andrew Campling
> wrote:
>> On 31 March, 2021, at 23:223, Bill Woodcock wrote:
>> To my observation, the position of TLD operators is split. Some of those
>> who directly face the costs of implementation would like to defer and
>> minimize those costs, and
-Original Message-
From: Bill Woodcock
Sent: 31 March 2021 23:23
To: Andrew Campling
Cc: Stephen Farrell ; Rob Sayre ;
dpr...@ietf.org
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption
On 31 March, 2021, at 23:223, Bill Woodcock wrote:
> On Apr 1, 2021,
> On Apr 1, 2021, at 12:12 AM, Andrew Campling
> wrote:
> It made me wonder whether there has been any dialogue with TLD operators to
> establish whether they are interested in adopting encryption?
> Some of the recent debate on the list seems to suggest that the position of
> TLD operators
On 31/03/2021 22:49, Stephen Farrell wrote:
> Hiya,
>
> On 31/03/2021 22:43, Bill Woodcock wrote:
>> Then those RFCs should be worded carefully so that they don’t suggest
>> that the thing they’re proposing is generally applicable.
>> Particularly to the roots. Which are actual critical
> On Mar 31, 2021, at 11:51 PM, Rob Sayre wrote:
> Look, this is just needlessly combative.
Ok. I was under the impression that you disagreed with the root server
operators, and believed that they should implement encryption.
If that’s not something you feel like fighting about, I certainly
On Wed, Mar 31, 2021 at 2:44 PM Bill Woodcock wrote:
> > On Mar 31, 2021, at 11:39 PM, Rob Sayre wrote:
> >
> > I think it's fine if you don't want to implement any given IETF RFC.
>
> Then those RFCs should be worded carefully so that they don’t suggest that
> the thing they’re proposing is
> On Mar 31, 2021, at 11:49 PM, Stephen Farrell
> wrote:
> The real issue IMO is not querying the root servers but
> the TLDs. There are still performance issues to consider
> of course but the business model and the value to the
> person somewhere behind the recursive are quite different.
>
Hiya,
On 31/03/2021 22:43, Bill Woodcock wrote:
Then those RFCs should be worded carefully so that they don’t suggest
that the thing they’re proposing is generally applicable.
Particularly to the roots. Which are actual critical
infrastructure.
There was a load of mail earlier today on just
> On Mar 31, 2021, at 11:39 PM, Rob Sayre wrote:
>
> I think it's fine if you don't want to implement any given IETF RFC.
Then those RFCs should be worded carefully so that they don’t suggest that the
thing they’re proposing is generally applicable. Particularly to the roots.
Which are
On Wed, Mar 31, 2021 at 2:34 PM Bill Woodcock wrote:
> So you’re saying that we all need to go spend some non-negative number,
> which, for us, is 3x-5x as much, in order that third parties should not
> know the relative volume of recursor cache-misses with respect to different
> TLDs?
>
> Why
> On Mar 31, 2021, at 11:28 PM, Rob Sayre wrote:
> Plenty of folks have evaluated the costs here.
And in all cases, they’re non-negative. Which is the point.
>> Could you state the problem that’s being solved?
>>
>>> > Sure, it's in the first sentence of
>>> >
On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock wrote:
>
> …and it’s measuring latency rather than server-side load. I just checked
> with our engineers, and it sounds like the server load per-query is more
> like 3x-5x higher for the encrypted queries.
>
Plenty of folks have evaluated the costs
> On Mar 31, 2021, at 10:51 PM, Rob Sayre wrote:
>
>
>
> On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock wrote:
>
>
>>> > On Mar 31, 2021, at 9:55 PM, Rob Sayre wrote:
>>> > I still don't understand the resistance here. Some data on what the
>>> > impact would be still seems like the most
On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock wrote:
>
>
> > On Mar 31, 2021, at 9:55 PM, Rob Sayre wrote:
> > I still don't understand the resistance here. Some data on what the
> impact would be still seems like the most helpful thing to move the
> conversation forward.
>
> We have that:
>
>
> On Mar 31, 2021, at 9:55 PM, Rob Sayre wrote:
> I still don't understand the resistance here. Some data on what the impact
> would be still seems like the most helpful thing to move the conversation
> forward.
We have that:
On Wed, Mar 31, 2021 at 2:13 AM Stephane Bortzmeyer
wrote:
> On Tue, Mar 30, 2021 at 05:00:29PM -0700,
> Rob Sayre wrote
> a message of 56 lines which said:
>
> > Why can't "The Root Server Operators" run QUIC etc as well as their
> > existing UDP methods?
>
> Just a note that DNS-over-QUIC
On 3/31/21 9:23 AM, Stephane Bortzmeyer wrote:
> On Wed, Mar 31, 2021 at 02:12:03PM +0100,
> Jim Reid wrote
> a message of 15 lines which said:
>
>> But the WG doesn’t seem to want to consider that.
>
> But what DPRIVE could do here? RFC 8806 is published. Besides sending
> its successor
On 3/31/21 9:40 AM, Stephen Farrell wrote:
>
> Hi Jim,
>
> On 31/03/2021 14:32, Jim Reid wrote:
>>
>>
>>> On 31 Mar 2021, at 14:05, Stephane Bortzmeyer
>>> wrote:
>>>
>>> RFC 7626 (the threat model and problem analysis that some people
>>> claim is missing) is clear (section 2.5.2 for
Hi Jim,
On 31/03/2021 14:32, Jim Reid wrote:
On 31 Mar 2021, at 14:05, Stephane Bortzmeyer
wrote:
RFC 7626 (the threat model and problem analysis that some people
claim is missing) is clear (section 2.5.2 for instance).
Stephane, RFC7626 is 6 years old. It predates the DoH and DoT (and
> On 31 Mar 2021, at 14:05, Stephane Bortzmeyer wrote:
>
> RFC 7626 (the threat model and problem analysis
> that some people claim is missing) is clear (section 2.5.2 for
> instance).
Stephane, RFC7626 is 6 years old. It predates the DoH and DoT (and soon DoQ)
specs. Some other risks have
On Wed, Mar 31, 2021 at 02:12:03PM +0100,
Jim Reid wrote
a message of 15 lines which said:
> But the WG doesn’t seem to want to consider that.
But what DPRIVE could do here? RFC 8806 is published. Besides sending
its successor on the standards track, what do you suggest the group to
do?
On Wed, Mar 31, 2021 at 03:15:14PM +0200,
Vladimír Čunát wrote
a message of 11 lines which said:
> So far I haven't noticed anyone pushing for encryption to the root.
Indeed. And this is why the root server operators statement is
surprising. It looks like a reply to some pressure to encrypt,
Hiya,
On 31/03/2021 14:12, Jim Reid wrote:
I know that Stephen. The point I was trying (and apparently failing)
to make was there are other privacy-friendly tools/protocols
available that could well be good enough solutions for some parts of
the problem space.
As an example, widespread
On 31/03/2021 14:00, Hollenbeck, Scott wrote:
-Original Message-
From: dns-privacy On Behalf Of Stephen
Farrell
Sent: Wednesday, March 31, 2021 8:58 AM
To: Jim Reid ; Brian Haberman
Cc: dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Root Server Operators Statement on
DNS
On 31/03/2021 15.12, Jim Reid wrote:
As an example, widespread adoption of RFC8806 - no sniggering at the back! -
could obviate the need for encrypted queries to the root or possibly offload
the TLS goop to the local instances of the root. But the WG doesn’t seem to
want to consider that.
> On 31 Mar 2021, at 13:58, Stephen Farrell wrote:
>
>> And is TLS the *only* game in town?
> When encrypting DNS based on some standard protocol? It is
I know that Stephen. The point I was trying (and apparently failing) to make
was there are other privacy-friendly tools/protocols
On Wed, Mar 31, 2021 at 01:00:43PM +,
Hollenbeck, Scott wrote
a message of 38 lines which said:
> [SAH] Why assume that encryption is required to provide confidentiality?
We never assumed that. RFC 7626 (the threat model and problem analysis
that some people claim is missing) is clear
> -Original Message-
> From: dns-privacy On Behalf Of Stephen
> Farrell
> Sent: Wednesday, March 31, 2021 8:58 AM
> To: Jim Reid ; Brian Haberman
>
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] Root Server Operators Statement on
> DNS Encryption
>
>
> Hiya,
>
> On
Hiya,
On 31/03/2021 13:52, Jim Reid wrote:
We all want better privacy of course. For some definition of privacy.
But what does that actually mean in the context of queries to
authoritative servers at the root or TLDs?
Workable answers for the root and TLDs are likely very
different, as the
> On 31 Mar 2021, at 13:33, Brian Haberman wrote:
>
> I was wondering the same thing. 8806 would definitely preclude the need
> to support encryption at the root.
This is one of the things that puzzles me about the current discussion. The WG
seems to be pushing TLS-based solutions and
On Tue, Mar 30, 2021 at 05:53:59PM -0700, Erik Kline wrote:
> On Tue, Mar 30, 2021 at 5:33 PM Stephen Farrell
> wrote:
>
> >
> > Hiya,
> >
> > On 31/03/2021 01:24, Eric Rescorla wrote:
> > > As I said earlier, this seems overly conservative given our experience
> > with
> > > large scale
On 3/31/21 5:24 AM, Stephane Bortzmeyer wrote:
> On Wed, Mar 31, 2021 at 10:44:08AM +0200,
> Vladimír Čunát wrote
> a message of 12 lines which said:
>
>> it's not so difficult to completely avoid querying root servers,
>> through one of the "local root" approaches.
>
> RFC 8806 does not
On Wed, Mar 31, 2021 at 10:44:08AM +0200,
Vladimír Čunát wrote
a message of 12 lines which said:
> it's not so difficult to completely avoid querying root servers,
> through one of the "local root" approaches.
RFC 8806 does not seem mentioned in the statement. Does anyone know
why?
On Tue, Mar 30, 2021 at 05:53:59PM -0700,
Erik Kline wrote
a message of 111 lines which said:
> I think, "IN NS com." doesn't reveal much information. But perhaps
> "IN NS sensitive-tld." could have privacy implications for some
> folks?
ir? cu? gay?
Also, while com/NS will be in the
On Tue, Mar 30, 2021 at 05:19:29PM -0700,
Rob Sayre wrote
a message of 69 lines which said:
> The DNSSEC stuff stood out to me. Why is that even seen as something that
> would help?
Because one of the ways to improve privacy at the root is local
synthesis of answers by the resolver,
On Tue, Mar 30, 2021 at 05:00:29PM -0700,
Rob Sayre wrote
a message of 56 lines which said:
> Why can't "The Root Server Operators" run QUIC etc as well as their
> existing UDP methods?
Just a note that DNS-over-QUIC is far from standard
currently.
On 31/03/2021 02.53, Erik Kline wrote:
I think, "IN NS com." doesn't reveal much information. But perhaps
"IN NS sensitive-tld." could have privacy implications for some folks?
Yes, it could be e.g. accidentally leaked garbage. But even so, it's
not so difficult to completely avoid querying
39 matches
Mail list logo
