ing, of fixed size per client
- It largely defeats use of DNS amplification, since the query packet
will already be as big as the biggest response. Of course, it doesn't
defeat anonymizing attacks, it just reduces the use of authority servers
for strictly amplification purposes.
Brian Dickson
O
On Wed, Mar 13, 2019 at 12:18 PM Christian Huitema
wrote:
> But then, if the user has not opted in such system, it would be nice if
> the ISP refrained from interfering with name resolution for that user. How
> do we achieve those two goals in practice?
>
> -- Christian Huitema
>
Even that
On Tue, Mar 12, 2019 at 3:51 PM Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> > On 12/03/2019 21:11, Paul Vixie wrote:
> > > ...
> >
> > There are reasons to want confidentiality for DNS queries
> > and answers, and access patterns, for which the IETF has
>
(Apologies for top-replying)
I think, from squinting at this a bit, that what is missing is some kind of
policy/service discovery, and coming to some kind of agreement (between
DNSOP and DOH, and any/all other interested parties) on what default
behavior should be (and under what
at 11:20 AM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
>
> On Wed, Aug 14, 2019 at 1:40 PM Brian Haberman
> wrote:
>
>> This starts a Call for Adoption for
>> draft-hal-adot-operational-considerations
>>
>> The draft is available here:
>
to contribute text, review, etc.
>
All of the above.
Brian Dickson
(Speaking for myself, but with the viewpoint of someone doing both
authority server operation and software development on authority server
software, intending to implement ADoT.)
>
> This ca
On Fri, Nov 1, 2019 at 1:10 PM Eric Rescorla wrote:
> It seemed like it might be a good idea to take a step back and talk
> about threat model to see if we're all on the same page.
>
> The set of threats I am concerned with is primarily about an on-path
> active attacker who learns the query
Sent from my iPhone
> On Nov 1, 2019, at 4:27 PM, Ted Hardie wrote:
>
>
> (cutting a good bit)
>
>> On Fri, Nov 1, 2019 at 12:54 PM Brian Dickson
>> wrote:
>>
>>
>> If the attacker does not have access to the timing data, IMHO the R2A
&
On Mon, Nov 4, 2019 at 12:37 PM Tony Finch wrote:
> Paul Wouters wrote:
> >
> > The right way to do this is a DNSKEY flag, which is protected by the
> > signed DS at the parent. Similar to draft-powerbind for the
> > delegation-only domain.
>
> That's per-zone, though, whereas DoT support is
On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters wrote:
> On Mon, 4 Nov 2019, Brian Dickson wrote:
>
> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> > be per-server a
On Tue, Nov 5, 2019 at 3:14 PM Warren Kumari wrote:
> On Tue, Nov 5, 2019 at 2:40 PM Paul Wouters wrote:
> >
> > On Tue, 5 Nov 2019, Warren Kumari wrote:
> >
> > > Because then I need to probe them on 853 and wait N before trying on
> port 53, or I will
> > > only get any sort of protection for
On Fri, Nov 8, 2019 at 4:18 PM Stephen Farrell
wrote:
>
> Hi Paul,
>
> On 08/11/2019 23:11, Paul Wouters wrote:
> >> I will also need to monitor the added load on the servers, although
> >> I don't expect it to be a problem.
> > That’s not an issue.
> >
> >> I realize that not everyone agrees
On Wed, Nov 6, 2019 at 9:31 AM Ted Hardie wrote:
> In-line.
>
> On Wed, Nov 6, 2019 at 9:05 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, Nov 6, 2019 at 8:21 AM Paul Hoffman
>> wrote:
>>
>>> Giv
On Thu, Oct 31, 2019 at 12:11 PM Jim Reid wrote:
>
>
> > On 30 Oct 2019, at 18:40, Livingood, Jason
> wrote:
> >
> > I agree that this is not a technical issue of scaling the root; that
> quantity of queries per day and second is not a big problem. Rather, as you
> note, it is a layer-9 issue.
On Thu, Oct 31, 2019 at 4:12 PM John Levine wrote:
> In article <
> cahbrmsdwdotqn8y5zk7rsvepjwwyateyaa6f0oj9desmafh...@mail.gmail.com> you
> write:
> >The ideas floated here about ADoT to the root are not, in my view, about
> >privacy (directly). They're about using ADoT to protect the
I scanned it briefly, and have a question about whether it makes sense to
consider a couple of syntactic/semantic additions.
I believe there would be more value to support explicit ordering as well as
randomization within a given set at the same level of preference.
I also believe adding rules
On Wed, Nov 6, 2019 at 8:21 AM Paul Hoffman wrote:
> Given that we are (still supposedly) talking about requirements and not
> solutions, I would be unhappy with a requirement that prevents a resolver
> that is not validating from being able to use encrypted transport to
> authoritative servers.
ng is being actively solicited. Send feedback to bdicks...@godaddy.com
please.
All credit for the DoT goes to my colleague Michael Sheldon (as do all the
GoDaddy DNS software kudos.)
We are supported by our excellent ops team including Brian King, Jason
Lynch, Frank Even, and Tyler Stanton.
Brian
Does anyone who was on the call, have the URI of the github doc, please?
Off-list response is fine.
Brian Dickson
On Fri, Oct 25, 2019 at 8:04 AM Brian Haberman
wrote:
> Hi Paul,
>
> On 10/25/19 10:27 AM, Paul Hoffman wrote:
> > On 10/25/19 6:25 AM, Brian Haberman wrot
On Tue, Oct 29, 2019 at 12:07 PM Ted Hardie wrote:
> On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz wrote:
>
>> FWIW, my expectation has been that ADoT would use TLSA-like
>> authentication, with no trust anchors other than DNSSEC (and nothing
>> resembling the WebPKI).
>>
>> Which certificate
Top-reply, which I think can potentially address all the underlying issues:
Make DANE support a SHOULD, along with publishing corresponding TLSA
records at the FQDN of the DNS server a SHOULD. Make the recommendation
that the certificate served include the full chain including CA cert.
This would
On Tue, Oct 29, 2019 at 5:02 PM Eric Rescorla wrote:
>
>
> On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie wrote:
>
>> Clipping away a bit where we appear to agree.
>>
>> On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz wrote:
>>>
>>
>> This resembles the ongoing experiment
>>
On Tue, Nov 19, 2019 at 4:23 PM wrote:
> > From: Add On Behalf Of Stephen Farrell
> >
> > If there were sufficient interest in the above from multiple
> implementers and
> > operators, then I'd be in agreement with Jari. I don't think we know if
> that is or is
> > not the case. (Well, I don't
On Tue, Nov 26, 2019 at 10:13 AM Stephane Bortzmeyer
wrote:
> On Tue, Nov 26, 2019 at 09:51:14AM -0800,
> Brian Dickson wrote
> a message of 98 lines which said:
>
> > However, if the only place the client is able to establish an
> > encrypted path to is a fo
On Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker
wrote:
> This notion of DNS resolver discovery seems very strange to me.
>
The larger issue (and the one I am interested in finding solutions for) is
that what is configured as a 'resolver', might actually be a 'forwarder'.
I.e. the path is
On Fri, Nov 1, 2019 at 10:34 AM Eric Rescorla wrote:
>
>> DNSSEC security is orthogonal to privacy, and is not a requirement FOR
>> PRIVACY.
>>
>
> I don't believe that that's correct in this case. The issue here is that
> in order to provide confidentiality for the queries (in this case to the
On Fri, Nov 1, 2019 at 9:13 AM Eric Rescorla wrote:
>
>
> On Thu, Oct 31, 2019 at 11:56 PM Vladimír Čunát <
> vladimir.cunat+i...@nic.cz> wrote:
>
>> Generally speaking, I believe it's fine to add assumptions about DNSSEC
>> validation, if that makes the ADoT protocol "better" in some way. (and
On Thu, Oct 31, 2019 at 7:38 PM Eric Rescorla wrote:
>
>
> On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for
>> privacy.
>> I.e. No need f
On Fri, Nov 1, 2019 at 11:37 AM Ted Hardie wrote:
> Hi Brian,
>
> On Fri, Nov 1, 2019 at 8:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>1. The operational cost of serving ADoT answers is prohibitive, due
>>to a number of
On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla wrote:
>
>
> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson wrote:
>
>>
>>
>> On 23 Jan 2020, at 13:53, Eric Rescorla wrote:
>>
>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson wrote:
>>
>>
>>
>> On 20 Jan 2020, at 22:37, Eric Rescorla wrote:
>>
On Wed, Feb 5, 2020 at 9:04 PM Adam Roach via Datatracker
wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-dprive-bcp-op-08: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines.
On Thu, Feb 6, 2020 at 9:31 AM Adam Roach wrote:
> On 2/6/20 09:08, Adam Roach wrote:
> >
> > For the specific example chosen, it's been made pretty clear over the
> > years that at least the clients for the specific service you cite have
> > no interest in incurring this additional cost. If
counter-measure, and that a softer
>> recommendation ("should") makes more sense otherwise.
>>
>> These are non-blocking comments, so I'm going to reiterate that the WG
>> can ignore them -- I just wanted to make sure they were considered. It
>> would be nice t
On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla wrote:
>
>
> On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> Top-top-top reply:
>> The Internet Threat Model you are using for web client-server is fine.
>> However,
orthless.
I'm also an advocate of RPKI (BGP resource pki to prevent route hijacking)
and RPKI ROA validation, and BGP route-leak-detection-mitigation (I'm a
co-author of that in the GROW working group).
Brian
>
> /a
>
> On 2/6/20 14:44, Brian Dickson wrote:
>
>
b 7, 2020, at 2:17 AM, Eric Rescorla wrote:
>
>
>
>
>> On Fri, Feb 7, 2020 at 12:19 AM Brian Dickson
>> wrote:
>>
>>
>>> On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla wrote:
>>>
>>>
>>>> On Thu, Feb 6, 2020 at 5:1
On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla wrote:
>
>
> On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk wrote:
>
>>
>> but given that the recursive has no way of knowing what the
>> DNS client is planning to do (and that some ~20% of web traffic does not
>> use TLS), it's hard for me to argue
Hi, Jim,
I was planning on replying to you with a just-for-you trimmed version, but
your email server refuses email I send (I use gmail... I know...), but
yeah, I will in future trim the replies.
Brian
On Mon, Mar 9, 2020 at 2:19 PM Jim Reid wrote:
> Could the people on this thread *please*
On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla wrote:
>
>
> On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla wrote:
>>
>>>
>&g
On Wed, Apr 8, 2020 at 10:04 AM Jim Reid wrote:
>
>
> > On 8 Apr 2020, at 17:55, Paul Hoffman wrote:
> >
> > This draft is better than earlier versions, but still is missing
> something that seems crucial: detailed comparison between the protocol
> described here, DoT, and DoH. The suggestion
On Tue, May 12, 2020 at 8:13 PM Ben Schwartz wrote:
>
>
> On Tue, May 12, 2020 at 8:15 AM Vittorio Bertola 40open-xchange@dmarc.ietf.org> wrote:
>
>>
>> Il 11/05/2020 21:35 Christian Huitema ha scritto:
>>
>> I found the discussion of application embedded resolvers bizarre. It
>> speaks of
On Fri, Mar 20, 2020 at 9:10 AM Ted Hardie wrote:
> On Fri, Mar 20, 2020 at 7:16 AM Ralf Weber wrote:
>
>> Moin!
>>
>> If the hardware and the location of the client and server are
>> identical it is impossible to get more throughput, better latency using
>> DoT or DoH, then DNS over UDP/53
>>
>>>
>>>
>>> On 29 Feb 2020, at 02:03, Eric Rescorla wrote:
>>>
>>>
>>>
>>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
>>>>
>>>>
>
On Wed, Jun 10, 2020 at 8:33 AM John R Levine wrote:
> >> That sounds quite painful for servers that serve hundreds or
> >> thousands of zones.
>
> I think this will work for NS with names in the zone. Still scratching my
> head about NS in other zones.
>
So, this seems to be failing
On Wed, Jun 10, 2020 at 12:29 PM John Levine wrote:
> In article eac7d...@mail.gmail.com> you write:
> >That leaks information to an attacker ONLY if the attacker has
> successfully
> >caused the resolver to get the wrong NS name at the first step.
> >
> >There is a method for preventing that:
On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote:
> I haven't seen anything written down that explains why it is difficult to
> do DoT to authoritative servers. There was a good discussion earlier this
> year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some
> of the issues. I
One issue that is likely to arise regardless of the specific technique used for
signaling availability of ADoT is the cost differential between popular and
less popular name servers (referring to number of zones and/or aggregate zone
popularity).
It is clear that the costs to revolvers will be
On Mon, Nov 16, 2020 at 5:28 PM Tony Finch wrote:
> Brian Dickson wrote:
>
> > Attempting to do XFR for many name servers which are infrequently used
> > would have scalability issues from any resolver, if the server names are
> > in a large number of zones. One approac
On Fri, Nov 20, 2020 at 11:47 AM Vladimír Čunát
wrote:
> On 11/19/20 2:05 PM, Peter van Dijk wrote:
> > 1. auth operators publish TLSA records for their NSes
> > 2. the registry, while generating zone files, queries for those TLSA
> records
> > 3. from the found TLSA records, the registry
On Tue, Nov 17, 2020 at 3:30 PM Tony Finch wrote:
> Peter van Dijk wrote:
> > On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
>
> > > Using TLSA records at _853._tcp. in a signed zone provides an
> > > unambiguous signal to use optionally TLSA, in a do
On Wed, Nov 18, 2020 at 6:29 PM Shumon Huque wrote:
> On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk <
> peter.van.d...@powerdns.com> wrote:
>
>> On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote:
>> [...]
>> > If (big if) we think it's worth upgrading the DNS delegation model (and
>> > EPP,
On Mon, Nov 16, 2020 at 2:02 AM Peter van Dijk
wrote:
> On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
> >
> > > > Using TLSA records at _853._tcp. in a signed zone provides
> an unambiguous signal to use optionally TLSA, in a downgrade-resistant
> manner
On Sun, Nov 15, 2020 at 6:08 AM Peter van Dijk
wrote:
> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
> > The most unambiguous signal possible, is the presence of a TLSA record
> on _853._tcp..
>
> That's quite a far reaching statement, and I believe it likely to
On Fri, Oct 30, 2020 at 2:45 PM Eric Rescorla wrote:
>
>
> On Fri, Oct 30, 2020 at 1:46 PM Paul Hoffman
> wrote:
>
>> On Oct 30, 2020, at 12:32 PM, Eric Rescorla wrote:
>> >
>> >
>> >
>> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman
>> wrote:
>> > On Oct 30, 2020, at 9:11 AM, Paul Wouters
>
>> Also, some folks on this list have already complained about added complexity
>> of discovery mechanisms.
>
> Please provide pointers or let them speak for themselves.
I realized after writing this that this was overly snarky and inappropriate.
It also occurred to me that you may actually
On Tue, Nov 3, 2020 at 6:15 PM Paul Hoffman wrote:
> Greetings again. I really like many of the changes in
> draft-ietf-dprive-phase2-requirements-02 and think that it gets closer to
> what we want for requirements. One of the requirements seems unnecessary,
> however.
>
>7. The
On Sun, Jan 24, 2021 at 11:56 AM Peter van Dijk
wrote:
> Hello,
>
> On Thu, 2021-01-21 at 08:54 -0500, Tim Wicinski wrote:
> > This starts a Working Group Last Call for draft-ietf-dprive-xfr-over-tls
> >
> > Current versions of the draft is available here:
> >
On Mon, Feb 15, 2021 at 1:20 PM Peter van Dijk
wrote:
> On Thu, 2021-02-11 at 13:54 -0500, Tim Wicinski wrote:
>
>
> Thanks Sara
>
> Folks should take a look at the changes, and those who raised issues can
> ensure
> these updates have addressed everything.
>
>
> This update works for me.
On Tue, Aug 24, 2021 at 11:38 AM Daniel Kahn Gillmor
wrote:
> On Thu 2021-08-05 11:06:12 -0700, Brian Dickson wrote:
> >- SVCB in the name server name's zone is where the signalling belongs
> >(on what transports are supported, per NS name, as well as
> authenticated
ting types.
I think it's fairly straightforward, but it is difficult to tell without
getting feedback, so please let me know what you think.
(The source is markdown, processed by mmark, and managed on github. Anyone
interested in contributing or commenting there, please contact me.)
Brian Dickson
On Tue, Aug 3, 2021 at 1:55 PM Paul Hoffman wrote:
> On Aug 3, 2021, at 1:34 PM, Ben Schwartz 40google@dmarc.ietf.org> wrote:
> >
> > In my view,
> >
> > 1. We should provide guidance on how to do unauthenticated DoT/Q using
> default-port probing, like we used to have in
>
This is the work I will be submitting in DNSOP.
It overlaps with the recent DPRIVE draft that Ben S submitted recently.
It will likely be the case that those overlaps need to be reconciled, based on
use cases and scope.
Comments are welcome.
It can be found at:
that the authors and chairs discuss this with the AD, IESG, and
get a read on this from the IAB. There may be a need to consult with
various liaisons or via liaisons to the other organizations, to determine
if this is okay to do without any actual changes to official policy
documents, or if it would requi
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson
A new version of I-D
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson
A new version of I
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson
A new version of I-D
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson
A new version of I
67 matches
Mail list logo
