[dns-privacy] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt

[Brian Dickson]

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, draft-dickson-dnsop-ds-hack-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-ds-hack
Revision:   02
Title:  DS Algorithms for Securing NS and Glue
Document date:  2021-09-19
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-02

Abstract:
   This Internet Draft proposes a mechanism to encode relevant data for
   NS records on the parental side of a zone cut by encoding them in DS
   records based on a new DNSKEY algorithm.

   Since DS records are signed by the parent, this creates a method for
   validation of the otherwise unsigned delegation records.

   Notably, support for updating DS records in a parent zone is already
   present (by necessity) in the Registry-Registrar-Registrant (RRR)
   provisioning system, EPP.  Thus, no changes to the EPP protocol are
   needed, and no changes to registry database or publication systems
   upstream of the DNS zones published by top level domains (TLDs).

   This NS validation mechanism is beneficial if the name server _names_
   need to be validated prior to use.




The IETF Secretariat
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Fwd: New Version Notification for draft-dickson-dnsop-glueless-02.txt

[Brian Dickson]

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-D, draft-dickson-dnsop-glueless-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-glueless
Revision:   02
Title:  Operating a Glueless DNS Authority Server
Document date:  2021-09-22
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-glueless
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-glueless-02

Abstract:
   This Internet Draft proposes a method for protecting authority
   servers against MITM and poisoning attacks, using a domain naming
   strategy to not require glue A/ records and use of DNSSEC.

   This technique assumes the use of validating resolvers.

   MITM and poisoning attacks should only be effective/possible against
   unsigned domains.

   However, until all domains are signed, this guidance is relevant, in
   that it can limit the attack surface of unsigned domains.

   This guidance should be combined with [I-D.dickson-dnsop-ds-hack]




The IETF Secretariat
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Fwd: New Version Notification for draft-dickson-dprive-dnst-00.txt

[Brian Dickson]

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, draft-dickson-dprive-dnst-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-dnst
Revision:   00
Title:  Resource Record for Signaling Transport for DNS to
Authority Servers
Document date:  2021-10-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.txt
Status: https://datatracker.ietf.org/doc/draft-dickson-dprive-dnst/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-dnst


Abstract:
   This Internet Draft proposes an RRTYPE to signal explicit support for
   transport types for DNS service.  This new RRTYPE is "DNST".  The
   available transports to signal are TCP and UDP on port 53 (DNS), and
   DoT (DNS over TLS) transport using TCP port 853.




The IETF Secretariat
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-06.txt

[Brian Dickson]

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-D, draft-dickson-dprive-adot-auth-06.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-adot-auth
Revision:   06
Title:  Authenticated DNS over TLS to Authoritative Servers
Document date:  2021-11-09
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-06

Abstract:
   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

   Additional recommendations relate to use of various techniques for
   efficiency and scalability, and new EDNS options to minimize round
   trips and for signaling between clients and resolvers.




The IETF Secretariat
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Review requested for DS glue

[Brian Dickson]

On Fri, Oct 1, 2021 at 8:07 AM Paul Hoffman  wrote:

> On Oct 1, 2021, at 4:50 AM, Brian Haberman 
> wrote:
> >
> > On 9/23/21 2:17 PM, Ben Schwartz wrote:
> >>
> >> I think this clarifies an important requirements question for the
> working
> >> group: do we intend to enable authenticated ADoT for names whose TLD
> >> doesn't do ADoT?  If yes, we need a way to authenticate the NS name and
> a
> >> signal for ADoT support.  If no, we can rely on the parent's ADoT to
> >> authenticate the glue (as suggested in draft-adox).
> >
> > I purposely waited a week to see if anyone would venture an answer to
> > this query. From my perspective, as co-chair, the lack of an answer is
> > quite telling. To me, it indicates that the WG is still not sure where
> > it wants to go with this work.
>
> If "this work" means authenticated ADoT, I agree. If "this work" means "DS
> glue", I disagree. The presence of DS glue for resolvers that are doing
> unauthenticated DoT allows for more encryption of DNS on the Internet.
>

Is there a document on the requirements for unauthenticated DoT, or a
comparison of things ADoT offers that unauthenticated's use case could be
handled by just ignoring some of those ADoT features?

As for "DS glue" (specifically the draft in DPRIVE with that name), there
is a vaguely similar draft by me in DNSOP that does a similar single thing
that is slightly similar to ds-glue, where the differences are important.

The "one thing" in the DNSOP draft is "supply DS record(s) that correspond
to NS records present at the parent, via new DNSKEY algorithm and existing
DS hash algorithms, intended to only validate/verify the published NS
records in the parent". This is consistent with the general policies
related to ICANN TLDs and use of DNSSEC records (which validate/verify
delegations and do not do anything else that impacts TLD policies, which I
believe are generally mandated by ICANN under Registry contracts.

What "DS glue" is proposing seems to me to be a significant departure from
existing TLD usage and policies, in particular publishing new DATA in the
DS records that preempts existing published data, using new DS algorithms
that the TLDs all need to support for it to be useful.

My concern is that the relationships between the larger organizations
(IETF, ICANN, Registries), where there are formal channels for asking
questions and proposing changes, may require obtaining permission in
advance of proposing significant policy changes.

I'd suggest 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 require policy level changes. At a minimum, even
without the liaison work, getting an informal buy-in from the major gTLD
registry operators is a crucial step.

Brian Dickson


>
> > I would contend that the only consistent
> > view I have heard from everyone is that there is not a need to
> > authenticate or encrypt to the root servers. After that, I see a lack of
> > consensus on:
> >
> > 1. ADoT support at TLDs
> > 2. ADoT support at parents for children doing ADoT
> >
> > Granted, in most cases #1 is a degenerate case of #2.
>
> Given that, can we move forward with the unauthenticated use case, for
> which there has been a lot of interest? Or do we have to reach consensus on
> one use case for both of them to move forward?
>
> --Paul Hoffman___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-02.txt

[Brian Dickson]

Hi, DPRIVE folks,

I have been working on the ADOT signaling and TLS validation problem.

This draft relies on a couple of short drafts I have submitted in DNSOP,
for the "unsigned NS record" and "unsigned glue records" problems.

There are a couple of mostly superficial additional RRTYPEs to support this
(a SVCB binding, and a TLSA aliasing), plus some EDNS options to reduce
round trip times.

I've included numerous examples, complete except for literal RDATA from the
examples for a few record types.

(I had said a fair while back, around the last IETF, that I would be
submitting something. I had some time off for vacation, and a short COVID
breakthrough, but finally got the drafts submitted.)

I think the scaling factors and round-trip times speak for themselves. The
methods are equally suitable for small or large DNS operators, and provide
full authentication with downgrade resistance.

It is not dependent on WebPKI, requires DNSSEC usage on the DNS operator's
infrastructure zone (where the addresses, signaling, and TLSA data are
served) but is otherwise very light on changes required beyond new RRTYPE
support, and even then involves new instances of existing 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


-- Forwarded message -
From: 
Date: Fri, Sep 17, 2021 at 8:27 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-adot-auth-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-adot-auth
Revision:   02
Title:  Authenticated DNS over TLS to Authoritative Servers
Document date:  2021-09-17
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-02

Abstract:
   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

   Additional recommendations relate to use of wildcard records for
   efficiency and scalability, and new EDNS options to improve round
   trips and signaling between clients and resolvers.




The IETF Secretariat
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] scope of authoritative signalling [Was: Re: [Ext] Intermediate proposal (what I was saying at the mic)]

[Brian Dickson]

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 or
> >not, etc)
>
> I'm agnostic about the mechanism specifically, but i am curious as to
> the rationale for the signalling being per-nameserver name.
>
> The plausible options for where to signal, as i see it, are:
>
>  a) signal per authoritative zone ("per zone") [excluding delegated
> subzones?]
>  b) signal per authoritative nameserver name ("per NS name")
>  c) signal per authoritative namserver IP address ("per IP")
>
> I think the *information* we're looking to signal, however we do it,
> consists of:
>
>  0) what forms of encrypted transport are available
>

I think what needs to be signaled, is what transports are available.
This could be traditional UDP/TCP, and/or DNS over TLS, and/or DNS over
QUIC, and/or any other transports.
Specifically, if the transport available is signaled as being "DNS over TLS
ONLY", that would be one way to prevent fallback.
Similarly, signaling "DoT or Do53", would be to explicitly signal that
fallback is permitted (in terms of what the zone admin and NS operator
offer).

Of course, whether a client (recursor) does fallback is a local policy
thing, if fallback is offered.
If fallback is not offered, then it is literally impossible to fall back.



>  1) what forms of authentication are available (including what
> public keys to expect?)
>  2) when and how to report problems with encrypted+authenticated
> transport
>  3) whether a recursor should hard-fail if the signalled
> authenticated+encrypted transport is not accessible (or, viewed
> as the inverse, whether fallback to port 53 is acceptable)
>
> It's possible that these four different pieces of data belong to
> different scopes.
>
> For example, it's possible that 0 and 1 should be signaled "per NS name"
> but 2 and 3 should be signaled "per zone".
>
> Consider the situation where the zone administrator is different from
> the NS operator.
>
> Semantically, as a zone administrator, i think i would *want* (2) and
> (3) to be "per zone", *not* "per NS name": i would want hardfail to be a
> choice *I* make, not the NS operator, and if it's going to be a choice I
> make, it needs to be a choice I can choose to gather data about, which
> means i need to be able to control reporting.  I can see why (0) and (1)
> might make more sense as "per NS name" operationally -- the NS operator
> knows what services they can deploy and what authentication mechanisms
> they can provide.
>

I see what you are saying here, and don't disagree. Or rather, what I am
getting at is, more than one NS name can exist for a given server and the
corresponding policy is tied to each specific name.
The zone admin would have control over which NS name is used,
hypothetically at least, and by way of picking the NS name(s), is able to
get per-zone behavior, while still having a scalable infrastructure (naming
scheme specifically).


There is a non-obvious benefit in using NS names for the attachment point
for policies (including transport, fall-back or fail-hard, etc.):  Multiple
names can point to the same IP address (IPv4 or IPv6).

If the NS operator chooses to do so, a suitable scheme can be used for
naming, that distinguishes "instances" of a given name server IP on the
basis of name.
Each of these instances can have its own policies, and those policies can
happily coexist.

Wildcards become your friend in this case, if a suitable naming scheme is
used, and a service binding (RRTYPE) is used so that no LEAFATTR values are
needed (e.g. _port._proto.NS_NAME).
Assuming a "dot" service binding were defined, which allowed for signaling
policies and supported transport(s), it would be quite scalable to group NS
names beneath a set of labels indicating policies, and using wildcards to
instantiate those policies.
(That's a lot of words, sorry. The example itself has way less in it.)
ns001.just-do53.example.net.   A IP_ADDR1
ns001.just-dot.example.net. A IP_ADDR1
ns001.dot-fallback.example.net. A IP_ADDR1
*.just-do53.example.net DOT 1 "." // service binding type, not alias type,
and use only default-ALPN which is DNS over UDP or TCP on port 53. The "."
binds this to the self-same name for the name used for the target.
*.just-dot.example.net DOT 1 "." no-default-alpn alpn="dot" // don't offer
DNS over UDP/TCP, only offer DNS over TLS.
*.dot-fallback.example.net DOT 1 "." alpn="dot" // keeps the fallback of
DNS over UDP/TCP, but 

[dns-privacy] DS delegation glue draft

[Brian Dickson]

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:

https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt


Sent from my iPhone___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Intermediate proposal (what I was saying at the mic)

[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
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-opportunistic-adotq-00
> .
> >
> > 2. Publishing a SVCB record should indicate support for authenticated
> encryption.  Nameservers that don't support authenticated encryption can
> offer opportunistic encryption based on default-port probing.
> >
> > 3. We should allow nameservers to indicate support for authentication
> via common PKI, DANE, or both.
> >
> > 4. SVCB and TLSA records are a firm promise, but resolver behavior is
> always up to the operator.  They can choose whether to "fail closed", skip
> authentication, fall back to UDP, etc.
>
> If the WG is going to go to DS in the parent to have a signed signaling
> response, it would make sense that the signal in the child have an
> identical format. If we go with that, I'd rather see CDS be used in the
> child instead of SVCB.
>
> I like using #4 as a way to bridge the two use cases (well, the stated
> unauthenticated use case and whatever fully-authenticated use case
> eventually gets published). That way, resolvers that have the
> unauthenticated use case have more reliable ways to get the signal, and
> also can get a signal for DoH.
>

Some (IMNSHO) important observations, and recommendation for direction on
these:

   - 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 or
   not, etc)
   - TTL on DS is controlled by the parent zone, and may not be appropriate
   for risky changes, thus not a good place for signalling
   - DS is a good place to protect the glue (NS records themselves, plus
   glue A and  records) - in fact, it is the only viable solution for that
  - DS for the NS needs to scale according the NS RDATA, not the owner
  names, so the DS per zone should not include the zone name (too
esoteric to
  discuss/debate this point, I think)
   - Signaling transport should be SHOULD, just to avoid port probing.
  - Opportunistic authentication is different from opportunistic period
  - It is better to signal transport and whether it is authenticated
  (in once place, the SVCB record)
   - The parent DS is per zone, not per name server, so that is NOT where
   transport/opportunistic signaling belongs (e.g. changing those MUST NOT be
   per zone)
   - There is a separate DS for the name server's names' zone, of course...
  - That is where the glue A/ records can be added to protect the
  resolution needed for querying for SVCB records
   - I don't think there is any reason to specifically support unsigned
   name server name zones
  - You need signed data to protect the information needed to get to TLS
  - It's integrity, not privacy, that is needed at this step
  - The first query to the NS name's zone cannot be TLS yet, because
  the info for TLS isn't available yet (catch 22)
   - TLSA allows signaling of WebPKI as an optional required validation
   over the certificate in the TLSA record (types 0/1 vs 2/3 IIRC).
  - Optional validation != optional WebPKI
  - You can have a signal that says "mandatory validation using TLSA
  but not WebPKI"
  - That signal could instead be, "mandatory validation using both TLSA
  and WebPKI"
  - Both are downgrade resistant
   - SVCB would signal DNS operators intent for failure mode
  - E.g. opportunistic (fail to fallback) vs mandatory (fail hard),
  subject to resolver's own policies (which could ignore DNS operator's
  signal)
   - If you require a signed zone anyway, and are going to do TLS (that's
   what we are discussing), then *requiring* TLSA records (with or without
   WebPKI) is a very easy thing to justify
  - Reminder: just because type 2/3 records don't require WebPKI
  validation, does not mean you can't use CA issued certs for those
  - It just means the validation avoids having to do WebPKI stuff.
  - DNSSEC signatures protect the cert fingerprint (EE or parental) in
  all cases
   - TL;DR: registrant zone gets DS with protection over NS RDATA; name
   server name delegation is similarly protected; name server name resolution
   at some point depends on glue A/ which also get DS protection; name
   server name has SVCB and TLSA records; SVCB signals opportunistic or not;
   TLS validation via WebPKI is signaled via TLSA; deployments and roll-back
   are handled strictly in the name server name's zone (including use of
   appropriate TTL values during deployment/rollback)

Resolvers can still work with this even if they don't do DNSSEC validation.
They do lose downgrade protection, but can still resolve fine.

Resolvers that do DNSSEC validation are 

Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-06.txt

[Brian Dickson]

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. Thanks!
>
> Me too, thanks.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-xfr-over-tls

[Brian Dickson]

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:
> > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
> >
> > The Current Intended Status of this document is: Standards Track
> >
> > Please review the draft and offer relevant comments.
>
> I like most of the draft. Some of it seems 'obvious' but often 'obvious'
> differs from reader to reader, so it's good to be explicit about a lot of
> things. So, I'm not here to say 'all of this is so obvious that the draft
> does not need to exist at all'.
>
> However, there's one part that bothers me. The 'intermingling' of multiple
> XFRs over a single connection (which is a SHOULD, not a MUST, so the
> document 'gets away with it', or conversely, implementations will get away
> with not implementing it) feels to me like a lot of additional code
> complexity for a gain that is not clear to me. XFRs are not latency
> sensitive to the point that TLS setup is an impediment.
>

I'm not one of the authors, but re-reading the draft with "intermingling"
in focus, I think the issues are:
- The intermingling aspect originates in RFC5936 (over TCP)
- They want parity between TCP and XoT (which is reasonable)
- Interoperability is assumed and not negotiated


>
> In other words, I do not think the goal 'minimize the number of TCP
> connections between a primary and secondary' warrants the complexity of
> intermingling XFRs. I'd much rather have a few more TCP connections, a few
> more TLS states, and a much simpler code base.
>
> We (PowerDNS) do not think we will implement the parts of the draft that
> call for such code complexity, and thus, we will serialise XFRs (serial
> connection reuse does make sense to me) and/or in fact open multiple TLS
> connections (like we do with TCP today). At least in our code base, TLS
> setup would never be the bottleneck for transfers anyway.
>

The relevant sections appear to be the text at the top of section 6.2, and
all of 6.3.2.

Servers MUST be able to handle multiple XFR requests.
Clients MUST be able to handle intermingled responses.
However, Servers MAY intermingle, rather than must, on the responses.

I concur with the code base complexity concern, particularly on the client
side.

I think this might be possible to accommodate with guidance (i.e. suggested
text to the following effect):
"NB: If clients do not want to support intermingled responses, a compliant
client could serialize requests to avoid multiple outstanding XFR requests.
If only one XFR is outstanding, no intermingling will ever occur."
Similarly, server-side guidance could be added:
"NB: if servers do not want to implement intermingled responses, they can
serialize the full XFR responses to individual XFR requests, and this would
be compliant. Similarly, reordering of XFR responses versus XFR requests is
allowed but not required (in order to be compliant)."


>
> Do any other vendors actually plan to implement such thorough connection
> reuse, with primaries actually intermingling multiple XFR responses over a
> single TCP/TLS session, and with secondaries actually firing off several
> XFR requests on a single connection to receive the zone chunks in whichever
> order they may come?


It is not clear if our (internal) implementations will do so, or how
(intermingling out-of-order serialized-but-not-interleaved, versus fully
interleaving of multiple XFR responses).

One possibility is the use of TLS proxies, which could multiplex multiple
XFR over TCP streams, such as from multiple TCP clients to multiple TCP
servers, across "shared" TLS XFR sessions (site to site). But that is
conjecture only at this point.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DOTPIN, TLSA, and DiS

[Brian Dickson]

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 generates DOTPIN DSes
> > 4. the DOTPIN DSes are published alongside the domain owner's NSes,
> DSes, and perhaps the DiS
>
> Intriguing but isn't it unnecessarily complicated? If we assume that
> DiS-like is possible, I'd rather replace the DOTPIN-related parts by
> some simple flag that tells if the zone's policy is to avoid cleartext.
>
> I.e., in comparison with today, the parent side would additionally sign:
> (a) the NS set - e.g. via DiS; that's because signing certs directly has
> those scalability issues
> (b) and this "policy flag" in some way (say, yet another DS alg like
> DiS, but there are other ways).
> The reasons are that I believe we want a possibility of downgrade
> resistance.
>
> More details: the rest of the trust chain could be TLSA or something
> similar on those NSs, looked up separately by a supporting resolver,
> assuming these can again be DNSSEC-validated (for now let me avoid
> trying to define the case when they can't).  Maybe this "policy flag"
> could be more than binary, too, e.g. allowing to indicate that the NSs
> may support DoT but it's OK if the supporting resolver isn't strict -
> and a third case might mean that resolvers shouldn't even attempt a
> secure transport (as optimization).  Of course, it's still not as nice
> as I'd like it (but maybe no perfect solution exists anyway), e.g.:
> - the TLSA lookup would add latency (at least I expect its TTL high
> enough to amortize for larger NSs), and
> - there are edge cases like privacy being hard for zones containing
> those TLSA records (circular dependencies; I expect we can sacrifice
> privacy of those TLSAs at least), and
> - it again assumes abusing DS - that's avoidable in theory but it may be
> too difficult to make the parent-side sign and return the necessary
> information in other ways (soon-ish).
>
> In retrospect I see that what I wrote is very similar to Manu's "Do9"
> except for replacing WebPKI by TLSA, with all their pros and cons:
>
> https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01
>
>
I think we (the three of us and maybe Tony Finch, if not the whole DNS
community) may be converging on a design that will, I believe, work.

I just checked on something that was nagging at me:
Is there a way to secure the NS set without requiring the delegated zone to
be signed?
I believe the answer is "yes", at least assuming implementers follow RFC
4035 correctly.

In section 5.2, the Nth paragraph reads:
" If the validator does not support any of the algorithms listed in an

   authenticated DS RRset, then the resolver has no supported
   authentication path leading from the parent to the child.  The
   resolver should treat this case as it would the case of an
   authenticated NSEC RRset proving that no DS RRset exists, as
   described above."


So, using a new algorithm for whatever we do, should be 100% backward
compatible.

The assumption is any resolver supporting the new algorithm does so
correctly, and

that any resolver that does not support the new algorithm does the
right thing (treat like unsigned).


This means the design can be as simple as "put stuff in an apex DNSKEY
record with a new algorithm)",

plus put the corresponding DS (hash of DNSKEY elements that DS uses)
in the parent zone, is sufficient.

Note that for TLDs, the mechanism for this would be EPP sending of DS
(or DNSKEY), and/or using

the CDS/CDNSKEY mechanisms.


There is likely use cases for separate new algorithms for protected
delegation items NS, A, and ,

all of which would be non-authoritative (and thus not signed by the
parent, but if encoded this way in

a DNSKEY, hashed as a DS, and signed indirectly by the parent, achieve
equivalency on protection).


Time to test some stuff and do some POC coding, and collaborate on a
draft with some folks.


Yay!


Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

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, and all the registries and registrars, and all the IPAM databases
>> and
>> > user interfaces, and documentation and textbooks), can we also tackle
>> the
>> > scalability problem? By "scalability" I mean the need for a hosting
>> > provider to update N delegations when a server cert changes. And
>> there
>> > are decades old problems keeping delegation NS and glue and DS records
>> > correct. (A large chunk of the "it's always DNS" meme comes from how
>> hard
>> > it is to understand delegations and update them correctly.) This whole
>> > area is a massive pain in the arse sorely in need of universal
>> automation.
>>
>> +100. I've referred to this in other threads - if CloudFlare had gotten
>> anywhere with their attempts to solve the operator / registrant /
>> registrar / registry disconnect problem, all of this would be so much
>> easier.
>>
>
> At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a
> challenge to DNS Operators to organize and become an officially
> recognized constituency within ICANN. If that were to happen, then it might
> be able to address and solve some of these issues over time, given
> adequate engagement.
>
> > Any serious attempt at improving delegations needs to deal convincingly
>> > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
>> > appallingly bad.
>>
>> Yes, or in the broader sense, my previous paragraph.
>>
>
> At the same workshop, Jim Galvin spoke about some of the structural reasons
> why it's challenging for the contracted gTLDs to make progress on
> supporting
> these (and also likely why there has only been adoption at a small number
> of
> ccTLDs, who are non-contracted parties). This was in relation to CDS and
> CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to
> date.
>

At the same Workshop, in our presentation I mentioned that we (GoDaddy) are
intent on providing CDS/CDNSKEY support.
This is to work around the logjam which is the RRR system and its
structural limitations.
Specifically, we will support our Registrar customers who are not DNS
customers, by polling them for CDS/CDNSKEY records no matter who hosts
their DNS.
We will then submit those via EPP (which we can do only because we are
their Registrar).

Nothing about this is rocket science, nor is it anything any other
Registrar cannot do.

It's a hack, but it moves the DNSSEC ball forward, and doesn't require any
new DNS "stuff" or Registry changes.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

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 downgrade-resistant
> > > manner.
> >
> > Not downgrade-resistant, until NS names in delegations become signed.
>
> Or until the parent nameservers support authenticated encrypted
> transports.
>
> Even so I think delegations should be signed.
>

So, the parental NS records are not authoritative, and thus not supposed to
be signed.

Has anyone ever experimented with how a signed delegation NS would be
handled by resolvers? (This might vary by resolver software and possibly
version.)

The signer field would differ between the delegation RRSIG and the apex
RRSIG (on what would otherwise be very similar RRSETs).
I.e. if you had zone.example.net NS ns1.something.example.com (and
friends), the apex RRSIG would have signer name zone.example.net, and the
non-apex delegation RRSIG would have a different (shorter) signer name.

Actually doing this as a protocol spec change would probably require that
the delegation RRSIGs would need to be cached differently (in the same way
the NS records are cached differently), and used accordingly.

The standardization of DNSSEC was before my time, so I don't know to what
degree this was discussed back then.
As much as making changes to those RFCs would be difficult and potentially
controversial, this might be the path of least implementation difficulty.
The big thing would be the signing overhead on large authoritative
(delegation-mostly) zones.

And I'm not sure whether the DPRIVE use case is enough of a "new
requirement" to justify changing the spec. But I think that is open to
consideration at least.

Fodder for discussion rather than a serious proposal, at least at this
point.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Amortization techniques for less popular name server names

[Brian Dickson]

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 approach to reducing this issue is
> > aggregating server names inside many fewer zones. Doing this aggregation
> > creates trust issues, however.
>
> Summarizing brutally :-) this sounds a bit like a combination between DLV
> and hyperlocal root zones?
>

Yes, exactly. (When I was writing it up, that thought even crossed my mind.)
The irony is not lost on me, either. :-)

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

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.
> > >
> > > Not downgrade-resistant, until NS names in delegations become signed.
> >
> > That's a moot point.
> > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
> 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
> based on the
> >DNSSEC validation state (as defined in [RFC4033]).
>
> Which buys you very little if the name you are looking up is from an
> unauthenticated source - like NS names in delegations.
>
>
Ah, okay, now I understand.

Yes, this is a huge gap in the fundamentals for any privacy architecture
(ADoT), which is rooted in the unsigned nature of NS records regardless of
the security state of a delegation (DNSSEC or not).

This pretty much impacts any solution that relies on either the names or IP
addresses of authoritative servers (the latter served as glue from the TLD).
An on-path active adversary (between recursive and TLD authoritative
server) would be able to modify these unsigned values.
Without any way to obtain them with some degree of protection (transport or
data), there is no path to connecting to the correct server initially over
TLS.

If the domain in question (the delegated domain, not the nameserver
namespace) is DNSSEC signed, it is possible to detect a discrepancy between
the delegation and apex NS records, assuming DNSSEC responses are not
blocked or tampered with.

If the domain in question is not DNSSEC signed, there is no defense against
such an attacker, if the query to the TLD is not protected by transport or
data security.

However, even in the signed zone case, confirming the apex NS records does
require a query to the authoritative server to verify things,
If the IP address used operates on port 853, there is no guarantee the
server responding is the actual authoritative server rather than an
attacker's server, since the name/IP could have been tampered with
initially.

This leads to a few possible conclusions:

   - With no changes to the DNSSEC management of TLDs (protocol and
   implementations), and with no availability of ADoT to TLD servers, an
   on-path active adversary :
  - Can defeat any attempt at privacy (ADoT) for unsigned zones
  - Can at most DOS any privacy mechanism for signed zones
   - The following techniques can alter the prerequisite conditions, each
   of which has deployment/operation concerns:
  - Changes to DNSSEC signing of (at minimum TLD) delegation data (NS
  records and glue A/ records)
 - Many large hurdles to overcome, including standardization,
 implementation, and deployment
 - May not be offered by all (or even any) TLDs
 - Availability of ADoT at TLD servers
 - Protects traffic via TLS
 - May not be offered by all (or even any) TLDs
  - Eliminating the on-path possibility, by obtaining the TLD zone via
  AXFR/IXFR
 - Protecting the TLD zone transfer is possible by either ZONEMD
 signature, or by doing AXFR over TLS
 - May not be offered by all (or even any) TLDs




> > So, downgrade-resistant, period.
>
> No.
>

I stand corrected.
Downgrade resistant only if the delegation information is protected (NS
names in particular).

Protecting the delegation NS records against an on-path adversary (between
resolver and TLD) does not have any nice solutions.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Amortization techniques for less popular name server names

[Brian Dickson]

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 amortized significantly if 
those costs depend on that popularity.

I would like to offer some suggestions for techniques that may be able to 
improve the costs towards less popular name servers.

These are not the only viable methods, nor is it the case that such methods are 
for certain necessary. However, if there arises a need for such a solution, I 
think it could be useful to have a possible solution in advance to address that 
hypothetical need. I don’t mind spending this effort, and am not married to the 
idea. If it isn’t needed, or if other solutions work better, that’s great.

These suggestions are in part to generally improve performance of DNS generally 
and to support privacy as much as possible. It is also partly to mitigate any 
possible  perception that there is any intent to leverage market position to 
influence the ADoT standardization process. Any ADoT solution should be 
evaluated neutrally, on the basis of meeting requirements, especially on a 
scalability perspective. Choosing a solution that scales badly but does so 
equally, would be a bad outcome IMHO.

So, what possible techniques could improve scaling for less popular name 
servers?
That depends on what those costs are and what scaling attributes they have.
I believe that the main costs would be computational costs and latency.
Latency can potentially be addressed by considering when any queries that are 
required occur. Early cache population  (rather than “just in time”) can reduce 
or eliminate such latency. (This is the classic space vs time trade-off.) Also 
worth considering are methods that replace queries and caches with use of 
secondary server functionality (on resolvers in particular) and notifies zone 
transfers. These have the additional potential benefit of being TTL-agnostic: 
they are as “live” as low TTL records, but as stable and performant as long TTL 
records.

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 approach to reducing this issue is aggregating server 
names inside many fewer zones. Doing this aggregation creates trust issues, 
however. This trust issue can possibly be addressed by using multiple (but 
still many fewer) zones containing aggregated sets of name server names, 
operated by different parties, and possibly registered in different TLDs and 
served in different jurisdictions. The presumption is independent operation 
reduces the risks of collusion, the impacts of operator error, and the risk of 
legal issues causing operational problems.

This is not without operation complexity. For instance, if secondary service 
was used, the operators of the aggregating zones would likely need to find a 
way of managing the client base of resolvers, or of publishing information to 
allow clients to validate transferred zones themselves.

There would still be operational cost, particularly if signed zones meant 
individual records required validation. One possible method of reducing the 
need for validation of signed records retrieved by XFR is the use of ZONEMD. It 
might allow for deferred validation or no validation of individual records, 
depending on what the resolver operator considered acceptable. (The zone digest 
would still need to be calculated and verified, but that is likely much less 
expensive.)

The example set up would be something like:

DNS operator:
snowflake.example.org NS small-ns-operator.dns-cooperative-one.example.net

Aggregate operator:
dns-cooperative-one.example.net ZONEMD value
dns-cooperative-one.example.net DNSKEY value
small-ns-operator.dns-cooperative-one.example.net  v6addr
privacy-thing.small-ns-operator.dns-cooperative-one.example.net TYPE value // 
eg TLSA record

ResolverX:
zone “ dns-cooperative-one.example.net” {
 type secondary;
 primary v6addr-of-primary;
 use-zonemd;
};

The end result in this example would be that ResolverX could have pre-populated 
ADoT info for rarely used nameservers, and be able to perform 
privacy-preserving queries to them with minimal incremental latency. 
(Establishing TLS session keys in advance would be one feasible way of speeding 
it up. Another would be maintaining open TLS sessions to every authority 
server, which might not be an available option depending on the policies of the 
authority server operators.)

Further scalability might be possible by using similar techniques such as 
catalog zones for publishing aggregator zones.

DNS software developers might ship example configs containing real aggregator 
zones to facilitate use of them.

The mutual benefit between small DNS authority operators and 

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

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 be
> wrong.
>
>
I think we can move this part of the discussion to the larger
thread/document started by Tony Finch.


> > Using NS names in a separate zone or zones (for each DNS operator) is
> scalable, and facilitates DNSSEC signing, at little to no incremental cost
> and little to no operational complexity
>
> The incremental cost for a resolver (doing a full resolution process
> for the TLSA records of one or more NS names) is not small, and neither
> are the latency costs. For 'popular' name servers, this cost can mostly
> be amortised, leaving the penalty with any domain hosted on a NSset
> that only has a few domains.
>

Okay, so my statement implied "to the operator of the name server(s)", not
the resolvers.

Resolver operators need to make their own decisions on whether to offer
privacy services, including whether there are any limits on which authority
servers they implement those privacy services towards.

I don't believe anyone has stated that there would not be any latency cost
or other cost (e.g. compute) for privacy services.

So, IMHO, any discussion on those costs needs to be done in relation to the
other attributes, such as "correctness" of the proposal.
Correctness would involve things like:

   - accommodating multiple server operators with different privacy
   settings (yes/no)
   - anycast dns server addresses where specific anycast instances may have
   different privacy settings (yes/no)
   - ability to differentiate privacy settings at a zone level via some
   mechanism
   - correct source of truth for privacy settings (i.e. must be the dns
   server operator, not the zone owner, to be the actual source of truth)
  - A clear example of the reason this source of truth is required, can
  be seen in the problem with NS records configured by the zone
owner rather
  than the DNS server operator: lame delegations.
   - cost to authoritative server operators (and scalability)

Again, this discussion should proceed in the other thread (Tony Finch's).


>
> > Using TLSA records at _853._tcp. in a signed zone provides an
> unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.
>
> Not downgrade-resistant, until NS names in delegations become signed.
>

That's a moot point.
TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
based on the

   DNSSEC validation state (as defined in [RFC4033
<https://tools.ietf.org/html/rfc4033>]).


So, downgrade-resistant, period. (Use of TLSA presupposes signed, in
other words.)



> (I proposed some solutions for that in other threads; Fujiwara has
> [independently, I think] now written a draft resembling one of those
> solutions
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
> )
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] how can we ADoT?

[Brian Dickson]

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 have done a braindump that attempts to cover all the
> angles reasonably systematically. I expect I haven't quite reached that
> goal though, so I hope this will provoke some informative comments :-)
> Since draft submission is closed, I'll paste it here for your delectation.
>
>
> ## Explicit encryption support signal
>
> How can a resolver know an authoritative server supports encryption?
> There are three basic alternatives:
>
>  1. No explicit signal: the resolver tries to make an encrypted
> connection, and falls back to cleartext if it gets an ICMP
> unreachable error or connection timeout.
>
> This is problematic because connection timeouts can be very slow,
> especially if the resolver tries multiple encrypted transports.
> This is also is vulnerable to downgrade attacks.
>
> The working group consensus is that an explicit signal is
> required.
>
>  2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
> resolver starts by connecting in the clear, and upgrades to an
> encrypted connection if the authoritative server supports it.
>
> This is vulnerable to downgrade attacks. The initial cleartext
> connection adds latency, and would need to be specified carefully
> to avoid privacy leaks.
>
>  3. Signal in DNS records: the resolver makes extra queries during
> iterative resolution to find out whether an authoritative server
> supports encryption, before the resolver connects to it.
>
> The extra queries add latency, though that can be mitigated by
> querying concurrently, and by placing the new records on the
> existing resolution path.
>
> DNSSEC can provide authentication and downgrade protection.
>
> This specification takes the last option, since it is best for
> security and not too bad for performance.
>

Agree strongly, for the reasons you mention.


>
>
> ## Where can nameserver encryption records go?
>
> Where can we put the new DNS records to signal that a nameserver
> supports encryption? There are a number of issues to consider:
>
>   1. Performance: we don't want the extra queries to slow down
>  resolution too much;
>
>   2. Scalability: is encryption configured per nameserver? per zone?
>

Also:
Per (anycast) instance/location?
Per operator?
Per tuple (for whatever N-tuple of factors makes sense, like (zone,
operator, location, nameserver)?


>
>   3. Authentication: DNSSEC does not protect delegation NS records or
>  glue address records;
>

At worst that allows MITM observation, and perhaps DOS, but cannot invalide
the authentication itself otherwise.


>
>   4. DNS data model: we ought to re-use existing RRtypes according to
>  their intended purpose;
>
>   5. DNS extensibility: make use of well-oiled upgrade points and
>  avoid changes that have a track record of very slow deployment;
>
>   6. EPP compatibility: a zone's delegation is usually managed via the
>  Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731]
>  [@?RFC5732] so any changes need to work with EPP.
>
> The following subsections discuss the possible locations, and explain
> why most of them have been rejected.
>
>
> ## In the reverse DNS?
>
> Given a nameserver's IP address, a resolver might make a query like
>
> _853._tcp.1.2.0.192.in-addr.arpa.TLSA?
>
> This possibility is rejected because:
>
>   * It would be very slow: after receiving a referral, a resolver
> would have to iterate down the reverse DNS, instead of immediately
> following the referral.
>
>   * At the moment the reverse DNS refers to the forward DNS for NS
> records; this would also make the forward DNS refer to the reverse
> DNS for TLSA records. Dependency loops are best avoided.
>
>   * It's often difficult to put arbitrary records in the reverse DNS.
>
>   * Encryption would apply to the server as a whole, whereas the
> working group consensus is that it should be possible for
> different zones on the same server to use encrypted and
> unencrypted transports.
>
>
> ## A new kind of delegation?
>
> In theory, DNSSEC provides a way to update the DNS data model, along
> the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea
> is to introduce new DNSSEC algorithm types which indicate that a zone can
> include new types of records that need special validation logic.
> Existing validators will be able to resolve names in the zone, but
> will treat it as insecure.
>
> We might use this upgrade strategy to introduce new delegation records
> that indicate support for transport encryption. However, it would
> require a very long deployment timeline. It would also require a
> corresponding upgrade 

Re: [dns-privacy] Requirements for authoritative server preferences

[Brian Dickson]

> 
>> 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 speak for others.
Please accept my sincere apologies.

I would encourage more information about what (those?) folks want the use case 
or flow to generally look like. Eg do they want to use a secure transport for 
forwarding queries to a larger resolver which does the validation for them and 
return AD=1?
Also, it is possible for different secure transports to be used in a 2 or more 
secure transport chain, eg DoH to resolver, DoH to big forwarded resolver, and 
DoT to authority. That does not necessarily increase complexity on the first 
system.

Brian___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Requirements for authoritative server preferences

[Brian Dickson]

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 authoritative domain owner or their administrator MUST have
> the option to specify their secure transport preferences (e.g.
> what specific protocols are supported).  This SHALL include a
> method to publish a list of secure transport protocols (e.g.
> DoH, DoT and other future protocols not yet developed).
>
> If the WG does with DoT and/or DoQ, you can discover the server's
> capabilities by probing port 853 and TBD-Q, or maybe by finding TLSA
> records. There is only a need to "publish" a list of secure protocols if
> they include DoH or DoHoQ.


No, this is not accurate, and highly misleading. I am not casting
aspersions on your intent, merely calling out the correctness of the
argument.

The prevention of downgrade attacks requires publication of servers
capabilities and intents, including prefered or offered protocols.
This includes DoT.

Counter-argument: an active attacker can force a downgrade by selectively
blocking port 853 queries.
If the secure transport for DoT is published, this becomes a
denial-of-service attack rather than a downgrade attack.
Lack of publication converts the blockage to a downgrade attack.

There may be multiple authoritative servers in different topological
arrangements, so that the attacker is on-path for only some of those
servers.
In that situation, blocking the port 853 queries to one server would result
in the client (resolver) attempting port 853 connections to the other
servers (assuming the non-opportunistic client).

The existence of clients and servers who both want to do encrypted
transport requires that the design accommodate that, notwithstanding the
desire for others to be opportunistic in their approach.
There is no way to have it both ways. Either strict client-server with no
downgrade is supported by the signaling or it is not.

The needs of the strict crowd cannot be ignored without failing to reach
consensus.
The strict requirements do not actually impose any obligation on clients
wishing to only do weak opportunistic with no DNSSEC validation or any
other non-verification type activity.
As you note, there is no way to force a client to validate.
I don't believe anyone is saying otherwise.


> Also, some folks on this list have already complained about added
> complexity of discovery mechanisms.
>

Please provide pointers or let them speak for themselves.
We should be discussing the requirements first, and addressing whether the
discovery mechanisms are too complex. Those may in fact be implementation
issues that might be addressed without impacting the high level
requirements.


>
> In addition this SHALL include whether a secure transport protocol
> MUST always be used (non-downgradable) or whether a secure
> transport protocol MAY be used on an opportunistic (not strict)
> basis in recognition that some servers for a domain might use a
> secure transport protocol and others might not.
>
> It is impossible for a server to tell whether a resolver is
> authenticating, so being able to say "you must authenticate" is kinda just
> posturing. The choice of whether or not to connect should always be with
> the resolver. Further, if a resolver is using a mechanism that requires
> strict authentication, it truly doesn't matter what the authoritative
> server has said it wants.
>

I think you are misreading what this paragraph says.

What it really says (or should say) is:
A given domain may have multiple authoritative name servers.
It may be the case that some of those name servers offer secure transport,
and others do not.
It may also be the case that some of those name servers do not offer
non-secure transport (i.e. regular port 53).
The method of publication of availability of secure transport MUST be
capable of distinguishing the availability of secure transport on a
per-authoritative server basis, and the (un)availability of non-secure
transport on a per-authoritative server basis.
I.e. ns1.provider-x.net may do DoT only (no port 53), and ns2.provider-y.net
may not offer any secure transport (only port 53), and ns3.provider-z.net
may offer DoH as well as insecure transport (so port 53 and port 443/DoH).
A client may be opportunistic, and choose any of the three, or may choose
to only use port 53 (thus only ns2 and ns3).
A second client may want to use strict security only, and may support DoT
and DoH, and thus use ns1 or ns3.
A third client may want to use strict security only, and may only support
DoT, and thus use ns1 only.

The choice of secure or not is always available to the client.
However, any client wishing to use secure-only MUST be able to detect and
prevent downgrade attacks. This places 

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

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  wrote:
>> >> > I still believe the cost of authenticating a DNS(SEC) server is so
>> low
>> >> > these days (with ACME available at no cost and with full automation)
>> >> > that this draft is better not done.
>> >>
>> >> The cost in terms of CPU cycles is indeed low. That is not the cost
>> that is being considered when choosing opportunistic encryption. There is a
>> real cost to the system if entire zones get server failures due to
>> authentication mistakes made by the authoritative servers (not renewing
>> certificates, errors in TLSA records, upstream validation problems that
>> cause TLSA records not to validate, ...) or resolvers (dropping trust
>> anchors that are in use, bad validation logic for TLSA, ...).
>> >>
>> > How is this different from the transition of the Web to HTTPS?
>>
>
I think a better comparison (better meaning more relevance and closer
tracking of the transition and operation) would be the transition of SMTP
to SMTP using TLS without downgrade susceptibility.


>
>> The DNS data is already authenticated if they are using DNSSEC.
>
>
To quote Daffy Duck, "Ha! That's it! Hold it right there! Pronoun trouble."
:-)

The problem with the above statement is who "they" is.

It's actually not a real problem, as I believe the correct "they" is being
referenced. I merely want to put more emphasis on which "they" this is, for
clarity in the rest of the conversation.

In this context, "they" is "whoever is operating the authoritative DNS
servers" for a zone or set of zones.

It should be noted that for a given zone, it is possible that more than one
set of DNS servers, operated by different DNS operators, can serve a given
zone. If there is >1 operator, the failure of one operator to maintain all
the DoTA mechanisms (certs, TLSA records, DNSSEC signatures) does not
impact the zone availability. Thus, the architecture of an optional (I
prefer that over opportunistic) encryption scheme regarding that side of
the connection is not fatally flawed if the mechanism(s) used involving
those mechanisms can fail, so long as they fail safe.

The important characteristic is that whatever method(s) are used, they need
to be completely downgrade resistant to all attack mechanisms, and they
need to fail safe.


>
> I don't see how this is an operational difference. It's a difference in
> value proposition. This whole discussion is predicated on the idea that
> encrypting r2a is valuable; if it's not, we can just go home.
>
>
I agree with EKR. (Try not to be shocked, anyone.)


>
> Also, because the DNS is hierarchical, even a short-lived authentication
>> failure at a particular server will take out the ability to get data for
>> all zones beneath that one; this is not an issue in the web.
>>
>
> As a practical matter, a TLS failure at a site like Google or Facebook has
> a similar kind of impact. But those sites have figured out how to run with
> high availability, and I anticipate that the big DNS servers who have a lot
> of zones beneath them could do so as well.
>
>
I agree with EKR again.

I think the document we're discussing may need to be reworked in terms of
the way the optional ("opportunistic") encryption (DoTA) is controlled,
managed, and signalled. With a re-orientation of the perspective on that, I
think the choices become a lot clearer.

First, a simple assertion: DoTA is only possible/available if it is
configured by the authoritative DNS operator.
Thus, the control of the state of whether DoTA is available for zones
operated by that operator, resides entirely with the operator.
This also means that, depending on how DoTA availability is signalled or
detected, the methods of correcting faults in the DoTA operation can vary.
Thus, selecting signalling/detection mechanisms should take the corrective
actions available into consideration. IMHO this should actually dominate
the design.

Second, some analysis on the DNS operator's NS names, compared to the zone
names, is relevant, regardless of whether the operator is the zone
registrant or some other party.
Understanding this can help motivate elements of the design, or deciding
whether those are reasonable choices.
This includes costs, scaling, and operational practices, particularly for
which zones have (or require) DNSSEC, TLS certificates including TLSA
types, and operational practices.

Third, I'll restate it here: The important characteristic is that whatever
method(s) are used, they need to be completely downgrade resistant to all
attack mechanisms, and they need to fail safe.

Lastly, there is the standards process issue of whether any specification
for DoTA can or should be done without significant input from authoritative
DNS operators and 

Re: [dns-privacy] bootstrapping NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Brian Dickson]

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: if the delegating name server (e.g.
> >TLD) supports DNS-over-TLS-to-Authority (DoTA), and the resolver obtains
> >the unsigned NS over a TLS connection. ...
>
> Right.  We have to bootstrap somehow and this seems about as good as we
> can ask for.
>
> >The details involved in getting the TLSA record for the NS name are left
> as
> >an exercise for the reader (but are easy enough to figure out, they're
> >literally an exercise in 4033/4034/4035.)
>

I wrote "getting" meaning "querying/validating", not setting.


>
> The principle is easy. What's hard is the Provisioning Crudware(TM)
> that will have to be updated to handle TLSA glue. You might see this
> as a dealbreaker, with the alternative being to abuse DS or some other
> record that we hope the Crudware already handles.
>
>
No, this isn't TLSA glue... this is TLSA below the delegation point for the
authority server's zone (which is serving the NS name and has the TLSA
records for all those NS names).
It's TLSA on the child side of the delegation, which depends on either
trusting, or validating (somehow) the NS record for the delegation for the
zone owner's domain to the providers name server(s).
The TLSA record is for a name which is not subordinate to the zone owner's
domain, it is for a name operated by the DNS provider.

I.e. that is stuff the DNS provider is responsible for, and does not
require the zone owner to deal with.
The zone owner points at the right NS, and other than the initial DS
record, doesn't need to do anything else.


> >(The reason for this is mostly about how EPP handles host records needed
> >for maintaining TLD glue, and scalability of management of all of that.)
>
> See above.  It's not just EPP, it's the provisioning system for any DNS
> server
> that delegates a subtree to another server.
>

The presumption I make is that there is nothing to add for provisioning
this... it is literally piggy-backing on the NS, for getting the name used
for the TLS connection, and getting the corresponding TLSA record.
This still does have the problem to solve, for "protecting" the NS name
which is not signed.
The options I can think of there are DoTA to the TLD, or AXFR with TSIG or
ZONEMD, or direct queries with TSIG to the TLD.
None of these is scalable or nice, and the TSIG one requires de-anonymizing
the recursive operator, or at least registering specific TSIG keys via
unspecified anonymous/pseudonymous methods.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Brian Dickson]

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 to converge on the obvious aspects of all of
this, particularly scalability and TLS session persistence.

Use the NS name on the delegation (which is unsigned), assume that NS name
has not been altered in transit, and make a TLS connection to that NS
(which hosts the domain the client wants to query.)
If that NS name is in a domain protected with DNSSEC, its TLSA record can
be trusted after validation. At that point, it is then safe to do the
TLS-protected query for the target DNS information.

Doing things this way means resolvers can leverage persistent TLS
connections to the large providers' name servers (to make queries for all
the domains that share an NS), which is a win-win between the resolvers and
auth operators.
(Persistent TLS >> individual TLS connections per query. Or at least
resuming TLS connections versus new TLS set-up.)

However, the first step has a problem:
Without a secure way of obtaining the first element (the unsigned NS name
being used), the only way to confirm the authenticity of that NS name, is
to make a TLS connection to the name server, and getting the apex NS
records for the target zone.
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: if the delegating name server (e.g.
TLD) supports DNS-over-TLS-to-Authority (DoTA), and the resolver obtains
the unsigned NS over a TLS connection.
(The other method that comes to mind, is obtaining the delegation zone
itself, e.g. via AXFR, with some method of protecting the data integrity,
such as TSIG, or ZONEMD.)

The details involved in getting the TLSA record for the NS name are left as
an exercise for the reader (but are easy enough to figure out, they're
literally an exercise in 4033/4034/4035.)

The best practice for large providers will likely be to have glueless
delegations for the domain(s) under which these NS names reside, and
possibly having the nameserver names for the domains serving those names,
themselves be glueless (indirectly glued).
I.e. the intersection set of NS values used for the served domains of
customers, and the NS values used for the domains used by the operators,
under best practice should be the empty set, so no glue is needed for
customer domains.

But TL;DR: big providers will want to only use TLSA records for their NS
names, not for their client's, and generally are very unlikely to offer the
ability for clients to use "vanity" name server names for the IP addresses
of their name servers.
(The reason for this is mostly about how EPP handles host records needed
for maintaining TLD glue, and scalability of management of all of that.)

Unsigned NS records for the delegation are a huge problem in the
architecture of DNSSEC, and consequently also for TLS (regardless of
whether TLSA or WebPKI is used -- the problem is the name itself which is
not cryptographically protected.)
DoTA or AXFR (with TSIG or ZONEMD) or other ways of obtaining the unsigned
NS values in such a way as to protect the data integrity are the only
available fix currently.
The long term ideal solution would be to fix the DNSSEC (and possibly DNS)
design, but I don't see that as happening any time soon.

Brian
P.S. This is a general observation, not an assertion of a position of a
particular operators' practice per se.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

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 applications in general, but the way the text is set-up appears
>> to be a specific dig against Mozilla. Look at the text: "popular
>> applications directing DNS traffic by default to specific dominant
>> resolvers". It boils down to accusing some unnamed application of
>> deliberately contributing to centralization. I find that problematic, and
>> also very imprecise.. I think this should be rewritten in a much more
>> neutral way.
>>
>> I think this section has already been rewritten at least half a dozen
>> times, and every time there was a claim that it is not neutral (sometimes
>> even on text that previously seemed to be ok). Every time the authors put
>> the effort to rewrite it once again according to the comment, and every
>> time a new comment comes in saying that this is not enough. I admire their
>> patience.
>>
>> In any case, I don't know Mozilla's view on whether this is a specific
>> dig against them, but it is meant as a discussion on privacy impacts of a
>> specific deployment model, not of a specific company's policy. These
>> privacy impacts, even if with very variable views, have been the subject of
>> many conferences, articles and talks in the last couple of years - they
>> were not discovered in this document, and it would be weird if they were
>> omitted from a discussion on DNS privacy released in 2020. The fact that
>> Mozilla is at this time the only company adopting that model is just
>> coincidental, apart from perhaps reflecting the fact that others think that
>> that model is not a particularly good idea.
>>
>> In a modern environment, the concept of host is very fuzzy. We get all
>> kinds of special devices. We also get containers or virtual machines
>> running inside hosts. A browser is in practice such a container. There is
>> not a difference of nature between a separate subsystem like a browser
>> environment and a separate device. If a browser embeds its own stub
>> resolver, users can configure the resolver of their choice in much the same
>> way that they can configure the resolver of their choice using a device
>> configuration UI. There are differences in management, but these
>> differences fall largely outside the scope of the DNS privacy draft.
>>
>> In both cases, users are very likely to configure a well-known service.
>> There is not much the difference between setting the device's preferred
>> resolver to 8.8.8.8 and setting the browser's choice to "Google DNS"? In
>> both cases, the centralization effect results from the popularity of the
>> service, unless you are specifically accusing Mozilla of conspiring to
>> centralize the DNS. And a privacy RFC is not the right place to do that.
>>
>> You seem to miss the point, which is not about users setting their
>> preferred resolver at the application level, but about applications that by
>> default ignore the resolver settings in the device and pick their own
>> preferred resolver independently from the user.
>>
>> In a market in which there are few choices, indeed this behaviour
>> promotes centralization: we know that most users do not change the
>> defaults, and if most users of a popular application start using a single
>> resolver in place of a broad set of local resolvers scattered around the
>> Internet, of course the resulting traffic pattern is more centralized.
>>
>> We also know that centralization of the DNS is potentially a privacy
>> threat, as it makes it easier to track and correlate multiple activities by
>> the same individual. This does not seem contentious - it was actually the
>> first example in last year's IAB "DEDR" workshop charter.
>>
>
> That seems quite contentious to me.  Decentralization of the DNS is _also_
> a privacy threat: running your own recursive leaks your IP to every
> authoritative (far worse than ECS!), pinning yourself to a unique recursive
> makes you uniquely identifiable as you move across the network, and using a
> recursive whose identity is unknown is obviously a privacy concern.
>
> There are many possible resolution configurations, and none of them offer
> perfect privacy.  The exact tradeoffs between them are very much in flux as
> the relevant standards and practices evolve.  If the draft tries to cover
> this topic it should present all of the risks in these different
> configurations, but I think it would probably be wiser to avoid claims
> about the privacy properties of deployment architectures.
>
>
Please let me point out that there is a repeated false dichotomy, regarding
running your own resolver software.

There is one specific mode, which most resolver software supports:
forwarder.
The resolution chain would then be application - stub software - local

Re: [dns-privacy] [Ext] Call for Adoption: draft-huitema-dprive-dnsoquic

[Brian Dickson]

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 in the text that the
> comparison would be added after there are implementations seems like the
> comparison would be about speed, but comparisons about protocol complexity,
> security, and privacy seem incredibly important as well.
>
> I think those comparisons belong in a separate document. Which would leave
> this draft as just the spec for doing DNS over QUIC.
>

Yes, however that then begs the question of whether adopting this before
the other doc is complete, is a good idea.
At a minimum the other doc should be a blocker to publication of this one,
but I'd prefer to not adopt this until we have solid consensus around the
other (including anything particular that might inform the
design/implementation of this one).

Brian


>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt

[Brian Dickson]

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 given two similar written servers.
>>
>
> Hi Ralf,
>
> A trivial example in which this is not true is in the case where one or
> more routers in the network path maintain different queues for UDP and TCP
> traffic.  When this is the case, a robust queue for TCP and a meager one
> for UDP can easily mean that the end-to-end performance for the client is
> better for DoT (or DNS over TCP/53), simply because the loss on the UDP
> path is high.  This is especially true if you measure over a flight of
> queries (say, all the DNS queries a web page needs to resolve) and DoT
> keeps an open session for the whole flight.  To put this another way,
> if what you are measuring is the DNS component of page load time,  DNS
> timeouts for the lost UDP packets  in a queue-starved path can kill the
> performance.
>
> As Eric points out, we have to be careful to describe what we're measuring
> here, and there are definitely different views of what we're optimizing
> for.
>

What may have been overlooked and/or erroneously given too much weight, is
the single report being used to compare performance.
(I don't have the original report URI handy, but I'm sure many participants
here do.)

IIRC, the measurements were done exclusively from AWS locations, and
further cherry-picked by AWS location.

So yes, we need to be careful not only on what we are measuring, but how we
are performing that measurement.

IMNSHO, that report would be better characterized as anecdotal rather than
statistically representative of the real world.

I'm definitely not against productive discussions, but we should get good
data first.

An example of good data, are the experiments conducted by Geoff Huston and
George Michaelson from APNIC.
I'd encourage those asserting performance claims to work with them to get
reliable data that can be analyzed in this forum.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

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* trim their postings? It's hard to
> track the discussion when every email contains a jumbled set of a gazillion
> postings. Thanks.
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

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:
>>
>>>
>>>
>>> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>>>
>>>>
>>>>
>>>> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>>>>
>>>>>
>>>>>
>>>>> 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 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:
>>>>>>>>
>>>>>>>> Review comments attached:
>>>>>>>>
>>>>>>>>
>>>>>>>> COMMENTS
>>>>>>>>> S 3.1.
>>>>>>>>> >  described above, and may not have any confidentiality
>>>>>>>>> requirements.
>>>>>>>>> >  However, the same is not true of a single transaction or a
>>>>>>>>> sequence
>>>>>>>>> >  of transactions; that transaction is not / should not be
>>>>>>>>> public.  A
>>>>>>>>> >  typical example from outside the DNS world is: the web site
>>>>>>>>> of
>>>>>>>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>>>>>>>> should not
>>>>>>>>> >  be.
>>>>>>>>>
>>>>>>>>> Well, technically what you want to conceal is the origin of the
>>>>>>>>> transaction or its linkage to other transactions. The existence of
>>>>>>>>> the
>>>>>>>>> query for that A record isn't secret.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Suggest:
>>>>>>>>>
>>>>>>>>> “that transaction (and specifically the origin of that
>>>>>>>>> transaction) is not / should not be public."
>>>>>>>>>
>>>>>>>>
>>>>>>>> The parenthetical swallows the main sentence. The accurate thing to
>>>>>>>> say is:
>>>>>>>>
>>>>>>>> In general, the existence of a single query is not sensitive --
>>>>>>>> though there may be exceptions
>>>>>>>> for some very low use domains. However, the origin of a given query
>>>>>>>> may leak information
>>>>>>>> about specific users and the ability to link queries reveals
>>>>>>>> information about individual use
>>>>>>>> patterns.
>>>>>>>>
>>>>>>>>
>>>>>>>> To fit with existing text suggest:
>>>>>>>>
>>>>>>>>  However, the same is not true of a single transaction or a sequence
>>>>>>>>  of transactions; those transaction are not / should not be public..
>>>>>>>> A single
>>>>>>>>  transactions reveals both the originator of the query and the
>>>>>>>> query
>>>>>>>>  contents which potentially leaks sensitive information about a
>>>>>>>> specific user. A
>>>>>>&g

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla  wrote:

>
>
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>
>>
>>
>> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>>
>>
>>
>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> 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 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:
>>>>>>
>>>>>> Review comments attached:
>>>>>>
>>>>>>
>>>>>> COMMENTS
>>>>>>> S 3.1.
>>>>>>> >  described above, and may not have any confidentiality
>>>>>>> requirements.
>>>>>>> >  However, the same is not true of a single transaction or a
>>>>>>> sequence
>>>>>>> >  of transactions; that transaction is not / should not be
>>>>>>> public.  A
>>>>>>> >  typical example from outside the DNS world is: the web site of
>>>>>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>>>>>> should not
>>>>>>> >  be.
>>>>>>>
>>>>>>> Well, technically what you want to conceal is the origin of the
>>>>>>> transaction or its linkage to other transactions. The existence of
>>>>>>> the
>>>>>>> query for that A record isn't secret.
>>>>>>>
>>>>>>>
>>>>>>> Suggest:
>>>>>>>
>>>>>>> “that transaction (and specifically the origin of that transaction)
>>>>>>> is not / should not be public."
>>>>>>>
>>>>>>
>>>>>> The parenthetical swallows the main sentence. The accurate thing to
>>>>>> say is:
>>>>>>
>>>>>> In general, the existence of a single query is not sensitive --
>>>>>> though there may be exceptions
>>>>>> for some very low use domains. However, the origin of a given query
>>>>>> may leak information
>>>>>> about specific users and the ability to link queries reveals
>>>>>> information about individual use
>>>>>> patterns.
>>>>>>
>>>>>>
>>>>>> To fit with existing text suggest:
>>>>>>
>>>>>>  However, the same is not true of a single transaction or a sequence
>>>>>>  of transactions; those transaction are not / should not be public. A
>>>>>> single
>>>>>>  transactions reveals both the originator of the query and the query
>>>>>>  contents which potentially leaks sensitive information about a
>>>>>> specific user. A
>>>>>>  typical example from outside the DNS world is: the web site of
>>>>>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>>>>>  be.
>>>>>>
>>>>>
>>>>> I find this text a bit clumsy, but OK.
>>>>>
>>>>>
>>>>> Furthermore, the ability to link queries reveals information about
>>>>>> individual use patterns.
>>>>>>
>>>>>
>>>>> The key thing is "link queries as being from the same user”
>>>>>
>>>>
>>> OK - will include that.
>>>
>>>
>>>
>>>>>
>>>>>> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

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:
>>
>> Review comments attached:
>>
>>
>> COMMENTS
>>> S 3.1.
>>> >  described above, and may not have any confidentiality
>>> requirements.
>>> >  However, the same is not true of a single transaction or a
>>> sequence
>>> >  of transactions; that transaction is not / should not be public.
>>>  A
>>> >  typical example from outside the DNS world is: the web site of
>>> >  Alcoholics Anonymous is public; the fact that you visit it should
>>> not
>>> >  be.
>>>
>>> Well, technically what you want to conceal is the origin of the
>>> transaction or its linkage to other transactions. The existence of the
>>> query for that A record isn't secret.
>>>
>>>
>>> Suggest:
>>>
>>> “that transaction (and specifically the origin of that transaction) is
>>> not / should not be public."
>>>
>>
>> The parenthetical swallows the main sentence. The accurate thing to say
>> is:
>>
>> In general, the existence of a single query is not sensitive -- though
>> there may be exceptions
>> for some very low use domains. However, the origin of a given query may
>> leak information
>> about specific users and the ability to link queries reveals information
>> about individual use
>> patterns.
>>
>>
>> To fit with existing text suggest:
>>
>>  However, the same is not true of a single transaction or a sequence
>>  of transactions; those transaction are not / should not be public. A
>> single
>>  transactions reveals both the originator of the query and the query
>>  contents which potentially leaks sensitive information about a specific
>> user. A
>>  typical example from outside the DNS world is: the web site of
>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>  be.
>>
>
> I find this text a bit clumsy, but OK.
>
>
> Furthermore, the ability to link queries reveals information about
>> individual use patterns.
>>
>
> The key thing is "link queries as being from the same user"
>
>
>> 
>>
>>
>>
>>>
>>>
>>>
>>>
>>> S 3.4.2.
>>> >  services available.  Given this, the choice of a user to
>>> configure a
>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>> >  transport to use in all network environments can actually serve to
>>> >  identify the user as one that desires privacy and can provide an
>>> >  added mechanism to track them as they move across network
>>> >  environments.
>>>
>>> I don't understand this paragraph. It's not the choice of specific
>>> resolvers that leaks data, but the choice to turn on encryption, In
>>> fact, from an identification purpose, the more resolvers that support
>>> encrypted transport, the better signal this is.
>>>
>>>
>>> This was driven by an observation that many early adopters set up their
>>> own DoT server and used that from all their devices, which could act as a
>>> way to identify that user.
>>>
>>
>> 1. This seems like an edge case.
>> 2. We already have plenty of people running their own unencrypted
>> resolvers for other reasons.
>>
>>
>> I can live with removing this text, but it does seem there is something
>> to say about the fact configuring a single resolver for a device could
>> differentiate a user….
>>
>
> Sure, but this has nothing to do with DoH or DoT.
>
>
I think the text might be clearer if the bit "as one that desires privacy
and" were removed.
The issue isn't whether a specific user desires privacy, it is whether a
specific user can be identified and tracked.

This RFC update, is about privacy.
This particular section is on encrypted transport.
This paragraph is highlighting that configuring a static list of resolvers,
even if those use encrypted transport, may expose the user to privacy risks
due to that constant set of resolvers, as the user moves between networks.
And this risk is inversely proportional to the number of users of the
resolver.
Maybe this last bit needs to be added to emphasis why this is a risk?

It's about the fact that DoH/DoT don't protect against this or mitigate it,
even if the payload is encrypted. I.e. it doesn't not have anything to do
with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the problem.



>
>
>>
>>
>>>
>>> S 3.5.1..1.2.
>>> >
>>> >  o  communicate clearly the change in default to users
>>> >
>>> >  o  provide configuration options to change the default
>>> >
>>> >  o  provide configuration options to always use the system resolver
>>>
>>> I get that you think this is neutral, but all of this is equally true
>>> about dynamic discovery via DHCP, it's just that that's the status
>>> quo, so you don't notice it. In this context, this text is tendentious.
>>>
>>>
>>> The first paragraph of section 3.5.1.1 talks about the variability 

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

Top reply to keep it brief:
WebPKI requires online keys. It is a core part of TLS; encrypting something  
with the private key is the critical security function of the handshake.
DNSSEC does not require online keys. This is due to the communication model of 
DNS: publication. Once published, DNSSEC doesn’t care how you obtain the 
records. The validation depends only on public keys.
(There are instances where on-the-fly DNSSEC signing is done, of course; the 
general practice for how that is done is with HSM.)

Zone signing is generally done offline, and in many cases is done with an HSM. 
Keys that aren’t online are by their nature protected from compromise.

Some TLS keys may be protected with similar mechanisms, but it is nowhere near 
the percentage of DNSSEC.

DNSSEC validation is complete protection against an attacker who is not on-path.

Brian

Sent from my iPhone

> On Feb 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: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 that this document is making the wrong
>>>> recommendation about DNSSEC validation.
>>> 
>>> The question at hand is not about whether it ought to recommend DNSSEC 
>>> validation but rather whether the text around that, which implies that 
>>> failure to do so has a high risk of sending your sensitive *web* traffic to 
>>> the attacker, is accurate given the high fraction of Web traffic that is 
>>> protected with TLS and the likely even higher fraction of sensitive traffic 
>>> that is.
>> 
>> The issue around implied risk, is a longitudinal one.
>> 
>> For sake of argument, let's assume 100.0% of web traffic is TLS protected..
>> Let's also assume that of the privacy resolver operators, there is at least 
>> one that does not do DNSSEC.
>> 
>> If an attacker obtains the private key for *some* certificate for a web 
>> site, what is the risk for the customers of the two groups of resolver 
>> operators?
>> 
>> The risk for the DNSSEC validating operators' clients is zero if the web 
>> site is in a DNSSEC signed domain. 
>> The risk for the non-DNSSEC validating operators' clients is non-zero if the 
>> web site is in a DNSSEC signed domain.
> 
> I don't think we're getting anywhere particularly useful here, so I'll 
> probably make this my last response unless something particularly new emerges.
> 
> The ability of an attacker to compromise a given connection depends on (1) 
> the ability to intercept the wire traffic and (2) the ability to compromise 
> the TLS connection. A successful attack (as a general matter) requires both 
> of these abilities. Because there are a number of environments in which the 
> ability to intercept wire traffic is trivial (e.g., an open WiFi hotspot) TLS 
> is designed under the assumption that the attacker has ability (1), in which 
> case, the security rests on ability (2), which it might achieve in a number 
> of ways, with key compromise being one of them.
> 
> It is certainly true that defense in depth is a good thing and that measures 
> which strengthen the user's wire traffic against interception by the attacker 
> will generally increase security. However, it is neither the case that DNSSEC 
> validation is sufficient to guarantee this protection (contra your statement 
> above state above) nor that in the absence of DNSSEC validation compromise of 
> the user's data is a generally anticipated consequence (as implied by the 
> text in question). It is not sufficient because (1) the attacker may be 
> on-path, in which case it is irrelevant whether the client is able to resolve 
> the right IP address or (2) the DNSSEC signing key is itself uncompromised 
> [usually we just assume that keys are secure, but given that the scenario you 
> are positing for WebPKI failure is key compromise, DNSSEC signing key 
> compromise needs also to be in scope]. It is not necessary because, as has 
> been noted already, we generally assume that the WebPKI provides a reasonable 
> level of security on its own, although, as Adam observes, nothing is perfect.
> 
> -Ekr
> 
>>  
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

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 that this document is making the wrong
>> recommendation about DNSSEC validation.
>>
>
> The question at hand is not about whether it ought to recommend DNSSEC
> validation but rather whether the text around that, which implies that
> failure to do so has a high risk of sending your sensitive *web* traffic to
> the attacker, is accurate given the high fraction of Web traffic that is
> protected with TLS and the likely even higher fraction of sensitive traffic
> that is.
>

The issue around implied risk, is a longitudinal one.

For sake of argument, let's assume 100.0% of web traffic is TLS protected.
Let's also assume that of the privacy resolver operators, there is at least
one that does not do DNSSEC.

If an attacker obtains the private key for *some* certificate for a web
site, what is the risk for the customers of the two groups of resolver
operators?

The risk for the DNSSEC validating operators' clients is zero if the web
site is in a DNSSEC signed domain.
The risk for the non-DNSSEC validating operators' clients is non-zero if
the web site is in a DNSSEC signed domain.

The risk depends on the ability of the attacker to poison the cache.
The validating resolver cannot be poisoned if the zone is signed.
The non-validating resolver can be poisoned even if the zone is signed.

The fact of non-DNSSEC validation is very likely known, particularly given
the public nature of privacy resolver operators, and trivial to confirm
directly by using them as a resolver.
The non-validating operators will definitely be a target for such an
attacker.

It doesn't particularly matter which certificate is compromised, in
principal; the question is whether the web traffic for that site can be
compromised. If the DNS poisoning succeeds, the answer is yes.

An attacker is unlikely to do the poisoning attack unless there is a
benefit to doing so, such as already possessing the private key.

I don't have any particular knowledge of how often keys leak.

I do have a pretty good idea how easy it is to poison a resolver.

It is generally only a factor of, at most, bandwidth and the ability to
send queries as a resolver client.
And unlike the typical ISP or enterprise or small network, the resolvers
here have to be open for use to anyone.
This makes them particularly vulnerable to the conditions that facilitate
poisoning.
And it is precisely this that make the case for a MUST rather than a SHOULD.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

On Thu, Feb 6, 2020 at 12:58 PM Adam Roach  wrote:

> This is really getting off into the weeds.
>
> Brian -- a lot of your assertions seem to be predicated on some underlying
> assumption that WebPKI is worthless or nearly worthless. Can you clarify
> whether that's your stance?
>

Sure, that's easy.

WebPKI is valuable, for web traffic. Its strength is highly dependent on
ensuring the client is connecting to the correct server, i.e. that DNS is
not altered.
WebPKI is potentially able to be made much stronger by the addition of DANE
TLSA records, so that the specific choice of CA can be securely verified
(preventing the malicious issuance of competing certs).
WebPKI is also made much stronger by DANE TLSA, in that unpublishing a TLSA
record is more reliable for asserting the invalidity of a certificate than
OCSP or CRL methodologies. The latter, as I understand it, fail "unsafe",
where failure to contact the CRL or OCSP server does not block the web
connection. If web browsers implemented TLSA validation and failed "safe",
the impact of blocking DNS traffic for a domain would be the same, whether
for blocking the TLSA record or the A/ records - it would be a denial
of service, but would also be mitigated by the presence of DNS caching.

I'm highly in favor of WebPKI, and also in favor of improving the
protections against some fundamental weaknesses that currently exist, by
using already-defined IETF specifications (DANE).

In fact, I'll be an internal advocate for publishing TLSA records for CA
certs for customer TLS certs (type 0 TLSA records) once we have ubiquitous
DNSSEC signing. (TLSA requires DNSSEC).

In other words, I advocate WebPKI + DNSSEC + TLSA, and that is the exact
opposite of WebPKI being worthless or nearly worthless.
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:
>
>
>
> 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, for DNS, that is the wrong threat model, for several reasons.
>>>
>>>- The threat for DNS cache poisoning is recursive-to-authoritative,
>>>not client-recursive(resolver)
>>>- The DNS path will not generally be related to the data path, and
>>>for any parent zone, almost certainly will be totally unrelated
>>>- DNS recursive-to-authoritative is UDP
>>>- UDP DNS does not require that the attacker be on-path
>>>- Compromise of DNS caches via poisoning (by potentially off-path
>>>attackers) leading to compromise of user data is not exaggerated.
>>>- The compromise risk is per-cache, as well as per-authority-server
>>>and/or per-DNS record.
>>>
>>>
>> First, all of these are just consequences of the 3552 "attacker
>> completely controls the network" threat model.
>>
>
> Sorry, I'm not clear on what this statement means in this context, or what
> the implication of this should be inferred as being.
>
> Are you saying:
>
>- It should be assumed (per the threat model) that any/every attacker
>completely controls every network segment everywhere?
>- or, that only attackers who DO control some specific network segment
>are a threat?
>
> These have vastly different implications, clearly.
> If the first one is the case, are you conceding the precondition, that
> attackers can poison DNS caches arbitrarily, by manipulating all DNS
> traffic? If so, that argues in favor of DNSSEC validation by the resolver
> in all cases, as that is the only way the attack can be blocked.
>
> If the second one is the case, the bullet points you quote, contradict
> that assertion. Specifically, that off-path attackers do not need to
> control any network segment (let alone all network segments), to
> successfully poison a DNS cache. This also argues in favor of DNSSEC
> validation.
>
> If you mean something else, could you explain what you mean?
>
>
>
>>
>> Second, the text in question is about the effect of attacks on DNS on the
>> Web "Users may be directed to bogus IP addresses for e.g. websites where
>> they might reveal personal information to attackers."
>>
>>
> Correct, and I don't see anything you say here refuting the concern over
> DNS cache poisoning attacks, which result in bogus IP addresses directing
> users to m

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

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, for DNS, that is the wrong threat model, for several reasons.
>>
>>- The threat for DNS cache poisoning is recursive-to-authoritative,
>>not client-recursive(resolver)
>>- The DNS path will not generally be related to the data path, and
>>for any parent zone, almost certainly will be totally unrelated
>>- DNS recursive-to-authoritative is UDP
>>- UDP DNS does not require that the attacker be on-path
>>- Compromise of DNS caches via poisoning (by potentially off-path
>>attackers) leading to compromise of user data is not exaggerated.
>>- The compromise risk is per-cache, as well as per-authority-server
>>and/or per-DNS record.
>>
>>
> First, all of these are just consequences of the 3552 "attacker completely
> controls the network" threat model.
>

Sorry, I'm not clear on what this statement means in this context, or what
the implication of this should be inferred as being.

Are you saying:

   - It should be assumed (per the threat model) that any/every attacker
   completely controls every network segment everywhere?
   - or, that only attackers who DO control some specific network segment
   are a threat?

These have vastly different implications, clearly.
If the first one is the case, are you conceding the precondition, that
attackers can poison DNS caches arbitrarily, by manipulating all DNS
traffic? If so, that argues in favor of DNSSEC validation by the resolver
in all cases, as that is the only way the attack can be blocked.

If the second one is the case, the bullet points you quote, contradict that
assertion. Specifically, that off-path attackers do not need to control any
network segment (let alone all network segments), to successfully poison a
DNS cache. This also argues in favor of DNSSEC validation.

If you mean something else, could you explain what you mean?



>
> Second, the text in question is about the effect of attacks on DNS on the
> Web "Users may be directed to bogus IP addresses for e.g. websites where
> they might reveal personal information to attackers."
>
>
Correct, and I don't see anything you say here refuting the concern over
DNS cache poisoning attacks, which result in bogus IP addresses directing
users to malicious servers, etc.

If users are sent to the wrong IP address, this substantially weakens the
argument that WebPKI is sufficient protection.

Why are CLR and/or OCSP needed, if not to respond to compromised
certificates (meaning leaked private keys)?

Am I missing something about WebPKI, beyond the private key proof of
possession model?
(Everything else about WebPKI is about validating the requestor's authority
and identity, but that is all orthogonal to key control.)

A web server using a compromised key is only ever going to be visible to a
(potential) victim, and never to third parties including the legitimate
certificate holder, except incidentally to operation of the rogue server.

Brian


> -Ekr
>
>
> I haven't written up the details of the more effective cache poisoning
>> attacks, but have been sharing summary information for several years now.
>> (The underlying issue is IP fragmentation of UDP packets. This is one of
>> the contributing factors that the DNS Flag Day for 2020 will include
>> recommendations/requirements to not fragment.)
>>
>> I'd be willing to write up those more effective attacks, including a PoC,
>> but that won't likely happen for a few months.
>>
>> Brian
>>
>> On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla  wrote:
>>
>>> Thanks. I am just looking at this text, and I think it's inappropriate.
>>> To recap something I seem to be saying a lot lately, the Internet Threat
>>> Model assumes a Dolev-Yao-style attacker who controls the network between
>>> the client and the server. TLS is designed to be secure in this
>>> environment, and while the WebPKi is imperfect, suggesting that compromise
>>> of local DNS lookups leads to compromise of user data seems exaggerated, at
>>> least in the case of Web traffic.
>>>
>>> -Ekr
>>>
>>>
>>> On Thu, Feb 6, 2020 at 10:22 AM Adam Roach  wrote:
>>>
>>>> Top-posting because I agree with the facts as you present them. I just
>>>> reach a different conclusion based on these facts. To be clear, I think a
>>>> belt-and-suspenders approach is generally preferable. I am merely
>>>> suggesting 

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

Top-top-top reply:
The Internet Threat Model you are using for web client-server is fine.
However, for DNS, that is the wrong threat model, for several reasons.

   - The threat for DNS cache poisoning is recursive-to-authoritative, not
   client-recursive(resolver)
   - The DNS path will not generally be related to the data path, and for
   any parent zone, almost certainly will be totally unrelated
   - DNS recursive-to-authoritative is UDP
   - UDP DNS does not require that the attacker be on-path
   - Compromise of DNS caches via poisoning (by potentially off-path
   attackers) leading to compromise of user data is not exaggerated.
   - The compromise risk is per-cache, as well as per-authority-server
   and/or per-DNS record.

I haven't written up the details of the more effective cache poisoning
attacks, but have been sharing summary information for several years now.
(The underlying issue is IP fragmentation of UDP packets. This is one of
the contributing factors that the DNS Flag Day for 2020 will include
recommendations/requirements to not fragment.)

I'd be willing to write up those more effective attacks, including a PoC,
but that won't likely happen for a few months.

Brian

On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla  wrote:

> Thanks. I am just looking at this text, and I think it's inappropriate. To
> recap something I seem to be saying a lot lately, the Internet Threat Model
> assumes a Dolev-Yao-style attacker who controls the network between the
> client and the server. TLS is designed to be secure in this environment,
> and while the WebPKi is imperfect, suggesting that compromise of local DNS
> lookups leads to compromise of user data seems exaggerated, at least in the
> case of Web traffic.
>
> -Ekr
>
>
> On Thu, Feb 6, 2020 at 10:22 AM Adam Roach  wrote:
>
>> Top-posting because I agree with the facts as you present them. I just
>> reach a different conclusion based on these facts. To be clear, I think a
>> belt-and-suspenders approach is generally preferable. I am merely
>> suggesting that the "must" statement I cite may be stronger than is
>> actually advisable given that such an approach is merely a small increment
>> of security for protocols that are otherwise secured (e.g., HTTP, which is
>> the example the document chooses), rather than the sole defense, as may be
>> the case with other protocols.
>>
>> My top-line suggestion here is to choose a different example than HTTP.
>>
>> Secondary to that is a suggestion that the "must" statement really only
>> makes sense when it is a sole 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 to hear from other folks on the topic as well.
>>
>> /a
>>
>> On 2/6/20 11:57, Brian Dickson wrote:
>>
>>
>>
>> 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 that's the working
>>> > group consensus, then I have no interest in over-riding it. But
>>> > ignoring operational realities seems kind of ivory tower-ish, which
>>> > feels like the kind of thing that undermines the general credibility
>>> > of the rest of the document.
>>> >
>>>
>>
>> Could you please be more specific?
>>
>> When you say "for the specific service", do you mean DNSSEC?
>>
>> And do you mean the signing of DNS zones using DNSSEC, when you refer to
>> clients of that service?
>>
>> Perhaps you missed my microphone comments at the last IETF?
>>
>> Specifically that GoDaddy will be turning on DNSSEC for the vast majority
>> of its DNS hosting customers?
>>
>> This represents about 40% of the DNS zones on the Internet.
>> (The exact time frame is not set in stone, but we expect this to be done
>> in the first half of 2020.)
>>
>> Given that this significantly alters the calculus, I don't think that is
>> a good enough reason to object in and of itself anymore.
>>
>> The other aspect of this is the asymmetry involved in the defenses
>> against impersonation:
>>
>>- The choice to sign a DNS zone is under control of the zone owner
>>- The choice to deploy RPKI on routes (to protect against 

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

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 that's the working
> > group consensus, then I have no interest in over-riding it. But
> > ignoring operational realities seems kind of ivory tower-ish, which
> > feels like the kind of thing that undermines the general credibility
> > of the rest of the document.
> >
>

Could you please be more specific?

When you say "for the specific service", do you mean DNSSEC?

And do you mean the signing of DNS zones using DNSSEC, when you refer to
clients of that service?

Perhaps you missed my microphone comments at the last IETF?

Specifically that GoDaddy will be turning on DNSSEC for the vast majority
of its DNS hosting customers?

This represents about 40% of the DNS zones on the Internet.
(The exact time frame is not set in stone, but we expect this to be done in
the first half of 2020.)

Given that this significantly alters the calculus, I don't think that is a
good enough reason to object in and of itself anymore.

The other aspect of this is the asymmetry involved in the defenses against
impersonation:

   - The choice to sign a DNS zone is under control of the zone owner
   - The choice to deploy RPKI on routes (to protect against BGP hijacking)
   is under control of the IP prefix holder
   - Both methods rely on third parties to cooperate to achieve the
   protections offered
   - RPKI routing filters are now widely deployed, and RPKI registrations
   are substantial
   - The remaining issue is DNSSEC validation; many (most?) of the public
   recursive operators do this already

The logic should be, defend against all feasible attacks, rather than
justifying the non-defense in one area (DNSSEC for DNS) based on the
assertion that another area is not being defended (RPKI for BGP).

Brian


>
> I realize that my editing made one of the pronoun antecedents here go
> away. The second sentence should have said something more like "If
> keeping the current text is the working group consensus..."
>
> /a
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson]

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. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
>
>
>
> --
> COMMENT:
> --
>
> Thanks to the document authors, as well as everyone else who
> contributed to this document for all the work that went into
> its creation.  I have a handful of editorial suggestions that
> you may wish to take into account prior to publication. (I also
> have one request and one question in the list below.)
>
> I also support the first point of Alissa's discuss, and have
> elided several comments about Section 5.1.7 from my review
> below with the expectation that it will be removed.
>
> ---
>
> §1:
>
> >  Community insight [or judgment?] about operational practices can
> >  change quickly, and experience shows that a Best Current Practice
> >  (BCP) document about privacy and security is a point-in-time
> >  statement.  Readers are advised to seek out any errata or updates
> >  that apply to this document.
>
> RFC Errata are intended only to correct documents to reflect what
> the community believed they should have said at the time of publication
> (e.g., typographic errors, omissions in state machines), and not to
> provide updates to reflect later thinking. Please remove "errata or"
> from this sentence.
>
> ---
>
> §5.1.1:
>
> >  o  DNS-over-TLS [RFC7858] and [RFC8310].
> >
> >  o  DoH [RFC8484].
>
> Nit: For the sake of consistency, I would recommend either contracting
> both of these (e.g., "DoT" and "DoH"), or expanding them both.
>
> This same comment applies to the prose in section 5.1.2, as well
> as the titles of 5.1.3.1 and 5.1.3.2.
>
> ---
>
> §5.1.2.1:
>
> >  o  Mis-identification of a server by a client e.g. typos in URLs or
> > authentication domain names [RFC8310].
>
> It's a bit unclear which kind of URLs this is referring to. Based on the
> proposed mitigation, I suspect it's talking about the use of URLs to
> configure a DNS server? Consider clarifying the URL's purpose in this
> text.
>
> ---
>
> §5.1.3.2:
>
> The use of EDNS(0) padding is conspicuous by its absence from this
> section. Is this intentional?
>
> ---
>
> §5.1.4:
>
> >  DNS Privacy Threats:
> >
> >  o  Users may be directed to bogus IP addresses for e.g. websites
> > where they might reveal personal information to attackers.
>
> You might want to consider a different example than websites here. 80% of
> worldwide website traffic is secured by HTTPS, which means than any such
> attempts will be prevented by WebPKI certificate mismatches.
>
>
This argument ("any such attempts...") is flawed. (Apologies for the
directness; this is factual stuff.)

Here's why.

HTTPS certificate validation is based on the assumption that the client
connects to the actual IP of the server (aka "the real server").
The real server presents the certificate, and the TLS handshake proves that
the server possesses the private key of the certificate.

Loss of control of the private key is an issue ONLY if an attacker is able
to direct a client to an IP under control of the attacker.

The DNS component of WebPKI certificate validation is critical; it goes
"FQDN" -> DNS -> IP -> (TLS connection with SNI, get cert, validate cert
via handshake).
You can't connect to some random IP that hands you the cert you ask for,
you have to know you are contacting the legitimate web site first (via the
DNS to IP bits).

The issue isn't actually WebPKI *mismatches*, so much as it is about the
non-possession of the private key for the *real* certificate (or issuance
of another certificate matching the name).

If an attacker is able to obtain the private key, there is no difficulty in
obtaining the certificate itself (indeed, the real server serves it up, as
required by TLS).

The only roadblock to an attacker using a certificate after a private key
is obtained, is DNS.

Only DNSSEC can protect against cache poisoning attacks, by which an
attacker can direct clients to the IP under control of the attacker, and
succeed 

Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

[Brian Dickson]

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 forwarder, this leave open the possibility
> > that the forwarder->(forwarder->[...])->resolver might involve one
> > or more unencrypted connections.
>
> I'm not sure I understand the problem. This case is just an instance
> of a more general problem "the machine you talk with may betray you
> and no amount of cryptography will help here". The resolver can send a
> copy of all your requests to the NSA (or its chinese equivalent), or
> it could use a forwarder over an unencrypted connection. What's the
> difference?
>
>
The difference is whether the problem is fundamentally unsolvable vs a
solvable problem.

Clearly, a resolver which betrays your trust deliberately can't be fixed
with any technology, it's a layer-8 or layer-9 problem.

However, a forwarder chain may not be intentionally insecure, and may only
be the result of naive designs or lack of vendor support.

The resolver at the end of the forwarder chain may actually be trustworthy,
so having a way of talking directly to it, solves the issue.

It also does so in a way that does not adversely affect the DNS ecosystem,
and in fact doesn't adversely affect the resolver itself.

A forwarder (or chain of forwarders, or tree of forwarders rooted at the
resolver) sends every query to the resolver. Connecting directly to the
resolver does not change that load, it merely bypasses middle boxes that
are value-subtract devices.

If anything, DNS resolution should improve, since it would (in theory, at
least) reduce latency, and possibly reduce loss caused by (DNS) application
queueing compared to strict network-level (hardware) queue use.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

[Brian Dickson]

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 generalized as client -> forwarder* -> resolver (zero or
more forwarders).

Any DNS client, and any DNS server, when communicating, are unable to
distinguish whether the other is (respectively) a resolver or forwarder, or
a client or forwarder.

For the DPRIVE use case, it is hopefully clear that the path from the
client to the (ultimate) resolver, needs to be encrypted in order to
achieve privacy.

However, if the only place the client is able to establish an encrypted
path to is a forwarder, this leave open the possibility that the
forwarder->(forwarder->[...])->resolver might involve one or more
unencrypted connections.

Depending on the network(s) and presence of NAT(s), it may or may not be
possible for the client to communicate directly with the (ultimate, actual)
resolver.

It is also a potential issue in addressing this issue with any
mechanism(s), that intermediate forwarders and the resolver itself, may not
have FQDNs of any sort, may not have NSIDs configured, and may not have
public (globally unique) IP addresses.

So, the 'discovery' can involve any or all of, some naming method (for
things without FQDNs), path discovery, address discovery, and address scope
conflict detection, with the preferred result of client->resolver direct
connection with encrypted transport.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Add] Narrowed-down proposal

[Brian Dickson]

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 know anyway.)
>

I'm very much interested in working on the "Discovery of resolvers and
their capabilities and behaviors" item and the "Support for debugging and
analysis".

I have some ideas that might combine those two through mechanisms that
support both use cases, so it might be possible to reduce the list of items
by one.
(This may lead to an actual "DNS traceroute", BTW.)

I'd prefer to work with 2-3 co-authors to ensure progress and good
collaboration, not more and not fewer. Please contact me off-list if you
are interested, presuming (a) WG formation, and (b) WG chair approval.

I'm willing to contribute ideas and review the item "Local DNS caches (e.g.
partitioning, use of stale records)". (I think that one is particularly
important, and important to get right.)

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Add] Draft on the use of multiple recursive resolvers

[Brian Dickson]

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 for fallback to non-private servers would be
advisable, even if some configurations choose to exclude the fallback
server set.

(Whether this uses names with hints for corresponding IP addresses of
servers, or not, is another question; that might better be addressed
separately?)

Using bind-style syntax, I would imagine something like:

resolvers {
 policy round-robin;
 fallback timeout 2s;
 set 1 {
   pref 30;
   proto dot;
   servers { 9.9.9.9; 8.8.8.8; 1.1.1.1;}
}
 set 2 {
   pref 20;
   proto doh;
   servers {9.9.9.9; 8.8.8.8;}
   }
 set 3 {
  pref 10;
  proto dns;
  servers {1.1.1.1;}
  }
}

The concept would be to list the preferred sets of servers/protocols and
their respective preference levels, along with resolver selection policy
(possibilities could be best, round-robin, random-order, etc).
Fallback to lower-preference sets would be controlled by fallback policy.

The idea is to avoid privacy-impacting server/protocol selection generally
(resistant to downgrade attacks), if the client so desires.

Everything else in the draft would generally be applicable to the selection
policy within server sets.

This is a richer semantic than the traditional /etc/resolv.conf, but the
latter doesn't really support anything other than traditional port 53, so
being restricted by the old semantics seems unwise.

Brian

On Sat, Nov 16, 2019 at 3:38 PM Jari Arkko  wrote:

> I wanted to point people to a draft that Martin, Ted, and me recently
> submitted
> on the use of multiple resolvers. This is early work; comments and
> additional
> analysis appreciated.
>
>
> https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00
>
>This memo discusses the use of a set of different DNS resolvers to
>reduce privacy problems related to resolvers learning the Internet
>usage patterns of their clients.
>
> Jari
>
> --
> Add mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

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 with this level of
> >> caution/fear/lack-of-backbone (I am sure there are other
> >> descriptions people would prefer).
> > It’s far too late for that level of concern by you.
> It seems odd that you're telling someone what they
> ought not be worried about. Wouldn't it be better
> to be convincing that there's nothing to worry about?
> (E.g. via stats.)
>

I was curious as to whether there are any easy-to-find stats or other
information on validation failures.
(Short summary: not a lot, not detailed, mostly anecdotal or summary
information.)

The closest thing to stats I could find were:
https://www.theregister.co.uk/2018/02/28/dutch_name_authority_dnssec_validation_errors_can_be_eliminated/

The relevant information was that "The rate of validation error is now 30
per million DNSSEC lookups."

I'd say that is low enough to not worry.

More anecdotal stuff is at https://ianix.com/pub/dnssec-outages.html which
lumps together information about TLD failures (now very rare), sites with
failures (becoming increasingly uncommon and having smaller impact), and
durations (typically a week or less on average, but again, this is
anecdotal not statistical.)

My view is the pendulum is swinging in the other direction, i.e. that the
next push needs to come (and will come) from the signing of domains rather
than validating by resolvers, for leading aggregate DNSSEC uptake.

The support for DNSSEC signing in software, including management of
automated unattended signing, has drastically improved, to the point where
IMHO you would have to try to find software or operators that don't do
things to facilitate reliable signing.

YMMV, of course. But, fear of rampant validation failures is entirely
misplaced at this point. Enough validation is being done, that such
failures need to be considered the responsibility of the signers, not the
validators. Sign, by all means, but expect that resolvers will validate,
and take appropriate measures to monitor and alert on failures.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

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:
>>
>>> 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. Any protocol we develop for ADoT capability
>>> discovery should prevent downgrade attacks but should also work fine for
>>> resolvers that do not validate.
>>>
>>
>> Why?
>>
>> Or rather, let me put together a straw-man to attack.
>>
>> Suppose the requirement (for the protocol for establishing the encrypted
>> transport for actual ADoT or for discovery of ADoT parameters) was that
>> *for this record* the record must be signed and must be validated, but that
>> it placed no broader requirement on validation.
>>
>
> It seems odd to have the code and operations to do this on both signing
> and validation , but then use it intermittently.  That seems both hard to
> reason about and difficult to explain.
>

I was interested in Paul's reason for "do not validate", as to whether it
was the concerns of generally validating everything, versus having the code
and operations that do the validation.
I.e., is it the concern about some zones having signing errors, independent
from the ADoT thing?

More recent operational results have show vastly improved levels of correct
operation of DNSSEC, and many fewer problems showing up, although I don't
track that myself and don't have references handy.
(I think there was a thread recently on one of the relevant lists to that
effect, though.)
I.e. I don't think aversion to validation generally is rational, but I also
don't like all-or-nothing when it comes to validation. I see this as likely
being an MTI (mandatory to implement) thing, with knobs to allow operators
to disable (against "medical" advice, as it were).



>
>
>
>> I.e. TSLA for cert validation for the TLS connections used, which would
>> require DNSSEC validation (mandatory per DANE RFCs).
>>
>> That would mean resolvers that don't validate *generally*, but do follow
>> the protocol (and validate very specific records) would would fine. Would
>> that be an unhappy-making requirement, or would you be okay with that
>> hair-splitting on validation?
>>
>
> I don’t think this would be something to recommend, personally.
>

Exactly, you have very clearly made my point for me between your two
comments. :-)


>
> Ted
>
>>
>> Given that presumably *some* changes would need to be made to resolvers
>> for ADoT, IMHO the particulars of *what* changes should all be open to
>> discussion.
>>
>> Brian
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

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. Any protocol we develop for ADoT capability
> discovery should prevent downgrade attacks but should also work fine for
> resolvers that do not validate.
>

Why?

Or rather, let me put together a straw-man to attack.

Suppose the requirement (for the protocol for establishing the encrypted
transport for actual ADoT or for discovery of ADoT parameters) was that
*for this record* the record must be signed and must be validated, but that
it placed no broader requirement on validation.

I.e. TSLA for cert validation for the TLS connections used, which would
require DNSSEC validation (mandatory per DANE RFCs).

That would mean resolvers that don't validate *generally*, but do follow
the protocol (and validate very specific records) would would fine. Would
that be an unhappy-making requirement, or would you be okay with that
hair-splitting on validation?

Given that presumably *some* changes would need to be made to resolvers for
ADoT, IMHO the particulars of *what* changes should all be open to
discussion.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

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 name-servers which I’ve spoken to
> recently enough that
> > > I have them in cache — that works for e.g: ns1.google.com, but not
> ns0.nohats.ca
> >
> > Well, that's how we do things when remembering per-server
> > characteristics, which we need to do anyway in case of outages.
> >
> > Like EDNS0 support and DNS COOKIES support is remembered and cached,
> > why wouldn't resolvers do the same for this property. We didn't put
> > "ns-edns" out there in name hacks either. Why start now?
>
> For things like COOKIES I don't need knowledge of the server *before*
> I contact it -- when I want to lookup www.nothat.ca, and get back a
> cookie, I've learnt something useful for future connections.
>
> For privacy, I really don't want to have to leak the fact that I'm
> looking up secret.nohats.ca because I happen to be the first user who
> is (recently) asking for a name on ns0.nohats.ca.
> a.ns.facebook.com is popular and so in basically all caches, all the
> time - and so users looking that up would get privacy most of the
> time.
> ns01.kumari.net is (obviously) less popular, and so basically never in
> caches -- and so anyone looking up kink.kumari.net will be exposed.
>
> Now, I really don't think it is fair and right that people looking up
> Facebook (or Google) get privacy simply because those sites are
> popular, and people reaching my personal site don't.
> I could get privacy back by moving my DNS to a large commercial DNS
> hoster (ns59.domaincontrol.com is in many caches, much of the time),
> but this seems like an even worse push.
>
> I'd like some system where I can signal that I support DoT:
> 1: without my parent having to do anything (like be upgraded to support
> DoT)
>
> 2:  without having people to probe and wait for a timeout
>
> 3: with my users first connection protected, so they don't have to
> lookup safe.kumari.net (to make sure that the resolver knows that
> ns01.kumari.net supports DoT), or something like _dot.kumari.net
> before looking up secret.kumari.net.
>
> 4: without expecting everyone to support DNSSEC.
>
> I'd like to see something less stupid than ns01-dot.kumari.net, but I
> don't really see what else the child controls at the parent (without
> having a separate set of info / RR type / encoding stuff in DS, etc)
>

So, I'm going to rephrase some stuff, in an attempt to capture what I
believe are either (a) requirements, or (b) changes to DNS, in what you
describe.

Then, I'll ask some leading questions, and make some assertions, and see
where that goes. :-)

So, currently, there is no recursive-to-authoritative privacy standardized,
per se, even if there might be some early implementations (DoT in OTE at
godaddy for example).

The first question is, since no standard yet exists, why NOT include a
requirement for DNSSEC in order to do privacy to the authoritative, even if
only in the secure bootstrap process?
It's all green-field, right? I.e. excluding DNSSEC a priori seems overly
restrictive. (But let's leave that for now. But please answer this
question, it's something I'm interested in.)

Second, there seems to be an inherent leakage of information caused by an
association between the NS name of your domain and the domain and its
children.

Suppose the name server name, was decoupled from the domain you care about,
and all the information about that name server were in a different domain,
where the name of the name server was served from another name server whose
name was an in-bailiwick name for that other domain, and the query for the
name server for the domain you care about was only ever done over an
encrypted connection. (Whew.)

E.g.
kumari.net NS ns-ku.secret-nameserver-12345.net
secret-nameserver-12345.net NS ns1.secret-nameserver-12345.net
ns1.secret-nameserver-12345.net A 
ns1.secret-nameserver-12345.net  

Then have records for the DOT bits for both ns-ku and ns1 inside the
secret-nameserver-12345.net zone.
(Pick your poison on what those records would look like, anything from TLSA
records to A/ records to some new RR type, or even SRV records.)

The privacy stuff would be a two-phase privacy bootstrap.
First, do the query to get the needed privacy stuff for
ns1.secret-nameserver-12345.net over a non-private connection.
Then, do the query to get the needed privacy stuff for
ns-ku.secret-nameserver-12345.net over a newly-established DoT connection
based on the previous step.
Third, do the query toward ns-ku.secret-nameserver-12345.net over another
DoT connection based on the previous step, to obtain any records within
kumari.net in a private fashion.

To know that any given query towards secret-nameserver-12345.net was
intended to get the stuff for kumari.net, 

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

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 and orthogonal to the per-zone signaling of DoT support.
>
> Again, that would be russian roulette. If I get an NS RRset with 3
> nameservers, and only one of these has a TLSA record, what should I
> do ?
>

IMNSHO, that is something the domain owner needs to consider, much more so
than the resolver operator.

Specifically, this is something that should probably go into a BCP about
DoT:

If you plan on doing DoT and using TLSA records, it is RECOMMENDED that the
same level of redundancy for DoT servers is deployed as would be the
general case for DNS (i.e. two minimum).

(Along with an explanation of why not having TLSA records for at least two
distinct server names would create an availability/security weakness.)

Other than the question of just one TLSA, I think the recommendation on
what to do if only a subset of NS RRSET members have TLSA records, is to
try to use all the ones that have TLSA records, repeatedly, before doing
anything else.
The "anything else" could be any of several things, from some variation of
"serve stale" to SERVFAIL to using Do53.

Brian


>
> 1) Pick the TLSA one
> 2) Pick a random one
>
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>
> For 2) the clients get reduced privacy for no good reason, so why would a
> client do this?
>
> It is really a per-zone property, not a per-nameserver property.
>
> Paul
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

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 per-server.
>

Well, it kind of depends, i.e. yes and no.

E.g. a DNS hosting provider might (or might not) apply the DoT support to
all the zones hosted on a given server, which has the effect of being
per-server, while still being implemented at a per-zone level.

Per-zone also is much friendlier to multi-provider (primary/secondary), in
those cases, i.e. prevents targeted downgrades on such zones (presuming the
secondary actually serves on the DoT port).

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 and orthogonal to the per-zone signaling of DoT support.

(The analogy would be routing registries and routing announcements. You
have to have the registration done first before the announcement, but the
registration and the announcement are distinct elements. Similar also to DS
and DNSKEY records.)

Brian


>
> DS records that somehow encode NS target names in their rdata might
> work...
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> partnership and community in all areas of life
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Threat Model

[Brian Dickson]

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 
>> queries expose no PII, since the query data cannot be associated with an 
>> originating client.
> 
> In the cases where EDNS Client Subnet is used, it does seem to associate the 
> query with a pool of potential clients even when there is no timing data; 
> depending on the size of that pool, this could easily represent a loss of 
> privacy.

Yes, ECS adds a whole extra dimension to the problem space. The particular 
issue arises entirely due to the source of the need for ECS.

It is an additional argument against centralization, at least from the 
perspective of comparing no-ECS to ECS. I think this was already telegraphed by 
Mozilla’s TRR requiring encryption to auth for use of ECS.

The degree of information leakage is probably some function of the granularity 
of ECS prefixes and the number of active clients on each ECS subnet, on a per 
name basis.

>  
>> In this case, an on-path active attacker isn't actually a threat (!!).
>> 
> 
> Even without EDNS Client subnet, the active attacker now has access to new 
> targeting data.  Let us say that the active attacker sits in front of 
> vlogsite.example.  If the attacker sees a query for 
> free-disputed-territory.vlogsite.example, the information that specific 
> recursives are seeing that traffic may be of interest to one or more of the 
> parties disputing the territory.

I think you mean the attacker sits in front of the nameserver for 
vlogsite.example?

Maybe, but that prerequisite location is relative to the recursive and 
authoritative. In some cases, that may be a tautology (recursive is inside a 
given region, where all traffic exiting is known to be monitored, and the 
authoritative is outside). There may not be a privacy solution available at 
all, or not legally permitted.

I don’t doubt the interest of the attacker. I question whether additional DNS 
protocol stuff to address that specific issue has value if the eventual data 
traffic isn’t equally protected from detection (eg SNI), or whether that 
particular problem might be addressed better with a non-DNS-only solution.

>  
> 
>> If this strategy is used, this creates an interesting side effect.  On a 
>> busy enough resolver, the regular cache refresh traffic may be significant 
>> enough to negatively impact timing attacks against encrypted C2R traffic in 
>> determing IP/QNAME matches, even if port 853 is blocked and all traffic is 
>> on port 53.
> 
> 
> This is similar to the logic this working group used to conclude that doing 
> the client-to-recursive first was the right choice.  I don't think the fact 
> that it is still true when port 853 is blocked refutes the advantages of 
> encrypting recursive to authoritative traffic.
> 

Me neither. The point was more about the fact that an active attacker needs to 
reveal her existence, and the above assertion was that the attacker’s goal 
would not be guaranteed (and thus affecting the risk/reward math, possibly 
enough to discourage the attempt).

> 
>> This risk needs to be given context, specifically where are the client, the 
>> recursive, and authoritative, and whether an attacker is able to block port 
>> 853 to cause the downgrade?
>> The current passive attack does not require the attacker to expose her 
>> existence, while port blocking reveals the existence (if not the identity) 
>> of the attacker.
> 
> I think Eric's point is different from a standard downgrade by port blocking. 
>  If the attacker is on path and there is no authentication of the 
> authoritative server, then a back-to-back user agent can be used to eavesdrop 
> on the query traffic.  Your recursive makes a TLS connection to the attacker 
> and sends a query; the attacker reads it and retrieves the answer from the 
> authoritative server in order to provide you a reply.You get the right 
> answer (and can even use DNSSEC to check it), but the query stream still 
> leaked to the attacker.  This is an active attack (because the attacker 
> terminates the TLS connection and starts a new outbound connection), but the 
> result is equivalent to what a passive attacker would get from port 53 data.

Yes. So doing DoT without DNSSEC to protect against name tampering could allow 
an active attacker to MITM.

That point should be part of the operational recommendations: sign the name and 
addresses and ideally use TLSA.
(It also puts similar requirements on resolvers to validate the same data).

Regards,
Brian___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Threat Model

[Brian Dickson]

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 stream (i.e., the domains being
> queried) coming out of the recursive resolver. It's of course mostly
> inevitable that the attacker learns which authoritative servers are
> being queried, but I think we can all agree there's still plenty of
> information to leak here [0].
>

This is where IMHO there is a major distinction between the C2R and R2A
query streams and respective privacy metrics.

C2R traffic is always PII, since the client ID (IP address) and query are
combined (literally) in the query and answer.
(NB: the proposal for "oblivious DNS" is an interesting approach that
decouples those in such a way that the resolver itself no longer has that
PII.)

There are two related considerations:

   - Does the attacker has access to timing data (source/dest IP plus port
   number indicating that DNS is being queried), even if the C2R traffic is
   encrypted?
   - How frequently has a query previously been seen (possibly "never", to
   "only from one client", to "frequently and widely seen")?

If the attacker does not have access to the timing data, IMHO the R2A
queries expose no PII, since the query data cannot be associated with an
originating client.
In this case, an on-path active attacker isn't actually a threat (!!).

If the attacker does have access to the timing data (or raw query data),
then the details of the second question come into play, including when and
how the resolver performs queries.

Here are possibilities that I can think of (which might not cover all
possibilities, everyone is welcome to add to this list):

   1. First query ever, never been cached. Must obtain from authority in
   response to new query.
   2. Only queried once, about to expire (TTL), can be preemptively
   obtained to keep the cache full.
   3. Queried multiple times by a single client, about to expire (TTL), can
   be preemptively obtained to keep the cache full.
   4. Only queried once, expired. Must obtain from authority in response to
   new query.
   5. Queried multiple times by a single client, expired. Must be obtained
   from authority in response to new query.
   6. Queried multiple times by multiple clients, about to expire (TTL),
   can be preemptively obtained to keep cache full.
   7. Queried multiple times by multiple clients, expired. Must be obtained
   from authority in response to new query.

Case #1 is obviously a rather unique case. It will always leak information.
The other 6 cases are pairs with the same semantic on the three cases that
differ only in numbers of queries and numbers of clients.
The following apply to all 3 of those pairs:
If the cache entry is allowed to expire, the next query would necessarily
leak information, as it becomes effectively a degenerate version of case #1.
If the cache entry is not allowed to expire (by preemptively doing a query
to keep the cache fresh), there might not be an association between the
query traffic (C2R) and the cache refresh traffic (R2A).
I.e. there might not be any information leak.

I believe it is the case that:

   1. If no cache entry exists and the R2A query is encrypted, there is no
   leakage. (Required for case #1, or TTL expiry every occurs).
   2. If a particular cache entry that has not been sent in the clear
   previously, and is refreshed before TTL expires, no information leak
   occurs, and it can continue to be treated as if it has never been sent in
   the clear.
   3. Only if a query has never been seen, or the TTL expires, AND the next
   query resulting in R2A is sent in the clear, does information leak.

If this strategy is used, this creates an interesting side effect.
On a busy enough resolver, the regular cache refresh traffic may be
significant enough to negatively impact timing attacks against encrypted
C2R traffic in determing IP/QNAME matches, even if port 853 is blocked and
all traffic is on port 53.


>
> In the current DNS, such an attacker can of course just perform a
> passive attack by listening to the DNS query traffic. It's possible to
> straightforwardly exclude this attack by opportunistically attempting
> DoT [1] to the authoritative. However, an active attacker can mount a
> downgrade attack on the negotiation, forcing you back to
> cleartext. So, unless you have a secure way of:
>
> (1) knowing the expected name of the authoritative for a given query
> and that it supports DoT
> (2) verifying that the server you are connecting to actually has
> that name
>
> Then the attacker can just mount a MITM attack on your connections and
> collect this data by proxying the traffic to the true authoritative.
>

This MITM attack method would work, and should be protected against, in
response to downgrade attacks against 

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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 factors
>>
>>
Correction/clarification: This should have read "of serving ADoT on all
traffic" (is prohibitive, or likely so).

The main gist of this is a desire to establish requirements that avoid the
need for all authority traffic to be ADoT in order to achieve privacy.
(The presumption is that ADoT is in effect an agreement between recursive
and authoritative, and requires the consent of the authoritative.)

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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
> authoritative) you need to authenticate the resolver. And that means
> authentically learning the name of the resolver. So, for instance, if I go
> the learn the NS for .com and the attacker gives me www.attacker.com,
> then he can learn my queries. The name of the resolver can be authenticated
> by DNSSEC or (less strongly) by having each query protected via secure
> transport.
>
>
Unfortunately (and I agree that this is unfortunate) the design for DNSSEC
does not protect the NS record in the parent with a signature.

The secure delegation does provide a signed DS, which means the child
domain's DNSKEY can be validated, which protects the data on the child zone.

However, the NS record used for the delegation, being unsigned, means the
attacker can still MITM traffic towards the child zone.

The validity of the child zone's NS records is signed, as would the
corresponding A records if the NS *name* found in the child zone is also in
a DNSSEC signed zone.
(There is still the possibility of what amounts to "name chaining", e.g. if
the NS name of the zone serving the child zone's NS name, is itself in a
third zone, etc.)

Protecting against this MITM requires not only DNSSEC on the child, but
potentially DNSSEC on other related zones. It also requires that the
resolver obtain the NS record and related A/ records from the child,
and then validate the certificate at the name of the NS, using CA
validation or TLSA validation. TLSA validation avoids interoperability
issues on CA trust, and avoids potential circular dependencies. TLSA
validation only requires the use of the single DNS root of trust.

So yes, DNSSEC is necessary, but compared to current resolver
implementations (which don't always fetch the child NS data and validate
it), is not yet sufficient.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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
>> I expect it will)  It seems that DNSSEC will be much easier than this
>> new stuff.
>>
>
> Easier for who? The advantage of transport security in this setting is
> that the authoritative can just deploy it for all their users without any
> interaction with the user.
>

Perhaps someone who operates authoritatives at scale should speak to this?
Regarding DNSSEC ease of deployment:

   1. The DNSSEC deployment/operation constraint is a performance-at-scale
   issue. *The majority of the CPU cost of DNSSEC is on the signing, which
   does not depend on query volume.*
   2. Serving DNSSEC-signed zones may have some overhead due to NSEC/NSEC3
   responses for NXDOMAIN or NODATA (no RRTYPE) responses. *Non-NXDOMAIN
   responses are larger, which consumes bandwidth but largely has no
   incremental CPU cost.*
   3. NB: NSEC3 has additional overhead due to the requirement to hash
   queries first, which depends heavily on particular NSEC3 parameters.
   4. Enabling DNSSEC widely on authoritative servers is primarily a
   moderate cap-ex exercise, i.e. provisioning adequate signing capacity.
   5. Deploying DNSSEC for all users is very feasible, and *at least one
   significant authority operator intends to enable one-click deployment for
   all users in the very near term.*

Regarding ADoT ease of deployment:

   1. The vast majority of authority traffic is UDP today (e.g. 99% or
   more).
   2. ADoT requires TCP, and additionally requires TLS.
   3. Deploying the certificates required for ADoT is very manageable, i.e.
   easy.
   4. The operational cost of serving ADoT answers is prohibitive, due to a
   number of factors:
  1. Maintaining state, for TCP and for TLS
  2. Set-up overhead for TLS
  3. Ongoing encryption of traffic after set-up, e.g. AES computational
  cost, vs "copy bytes" (possible with DMA and no CPU)
  4. Deployment of ADoT without providing means for managing these
  costs is highly unlikely to happen
  5. Developing means to manage ADoT costs (in the standards, and in
  implementations) is highly non-trivial.
   5. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
   (Cheap, easy, fast, choose two, currently zero are available to choose.)

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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 for ADoT anywhere other than at the leaf zone's name server
>> (whose NS name might not be in-bailiwick, FYI).
>>
>
> Hmm I think that's only true if you are assuming that the NS record
> for the leaf is DNSSEC secured, but that doesn't seem like a safe
> assumption.
>

Let me re-emphasize this from the original statement: "FOR PRIVACY".

DNSSEC security is orthogonal to privacy, and is not a requirement FOR
PRIVACY.

I.e. it is always true.

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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 integrity of
> >(currently) unsigned data in the root zone.
> >
> >An alternative solution is to get ADoT bootstrap info from the child zone,
> >where it could be signed, before making a query that reveals the next
> >label.  This could work, but at the cost of an extra roundtrip.  (How
> often
> >this latency penalty applies depends on the details of the construction.)
>
> Thinking about it a little more, I think it is likely that there will
> be islands of ADoT sort of like there used to be islands of DNSSEC.
> For example, I expect the people on this list are likely to deploy
> ADoT long before some of the 2LD's above them. Moreover, all of the
> problems about getting your DS into the zone above would apply to
> getting your ADoT signal there.  Even with the cost of an extra lookup
> it's probably going to work better to have each island describe itself
> so you don't need an unbroken chain of ADoT from the root.
>

IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for
privacy.
I.e. No need for ADoT anywhere other than at the leaf zone's name server
(whose NS name might not be in-bailiwick, FYI).

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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. But I don't think we should constrain our
> requirements development & protocol design because of this.
>
> In principle, I agree with you. Though in practice, I'm questioning if it
> makes sense to work on ADoT unless there's a strong likelihood it will get
> mainstream deployment and adoption. [What's the point of producing
> something that won't see widespread use?] And surely if there's going to be
> ongoing protocol design work, that needs to take account of the concerns of
> those who run busy authoritative servers? AFAICT apart from a recent ID
> from Verisign, they have not been part of the discussion so far.
>
>
I think there will be both interest and deployment, sufficient to justify
the effort.

IMHO, including the ability for authority operators to signal support, may
be sufficient to address the concerns about the root servers, including
that they may have different levels of interest in supporting DoT.

E.g. Having a well-defined record at or under the NS name that indicates
support for transport protocols would enable each root-server.net instance
to signal whether DoT queries might be answered.

That itself might crack open another can of worms: DNSSEC signing of
root-servers.net, including possible naming choices for the root servers
(qv related investigative work that was being done by the RSSAC Caucus.)

One idea that was not considered previously, that just occurred to me: have
root-servers.net be DNSSEC signed, but without a secure delegation. It
would be an island of security that could be optionally be securely
accessible via adding a new trust anchor, specifically if/when a particular
resolver wishes to use ADoT to authority servers. I believe it would not
impact the priming responses.

(Also, I think the ADoT requirements should include an assumption that ADoT
is not supported unless the nameserver name explicitly signals such at or
under the nameserver's name.)

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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
>>  between Facebook and
>> Cloudflare, where both parties have agreed to speak DoT by hardcoding the
>> relevant parameters and special-casing the relevant authoritative servers.
>> They didn't need an ADoT standard to make this possible, because the
>> connection is a "closed system" based on an agreement between the two
>> parties.
>>
>> In your corporate-internal scenario, the recursive and authoritative
>> servers are even more closely tied, being operated and controlled by the
>> same party, so a secure upgrade protocol is much less relevant than on the
>> open internet.  The admins can hardcode whatever authentication procedure
>> they want.  They can even use pre-shared keys!
>>
>> Agreed, they could also use pre-shared keys.  But that means that we
>> should not require in the standard that they use a specific method, but
>> provide a method that works for the common case and allow for methods where
>> other things are driven by specific deployment conditions.
>>
>> Leaving that aspect aside, if we suppose that enterprise.example is a
>> signed parent zone, and internal.enterprise.example is an unsigned child
>> zone, we can still potentially enable DNSSEC-rooted ADoT to
>> ns.internal.enterprise.example, if we can find a way to put its TLSA data
>> in the parent zone.  I think this is worth attempting.
>>
>> I would really like to see a sketch of the design for that before it gets
>> to be a foundation of the approach.  I can picture both large flat zones
>> and deep hierarchies where it could end up being a real tangle.  But since
>> that tangle is based on my headcanon of the design, it's liable to being
>> very badly off.
>>
>> Put another way, I think you may need to support authentication using PKI
>>> trust anchors as well.
>>>
>>
>> Assuming PKI is used to validate the nameserver's name, I'm not sure it's
>> sufficient, because this name is potentially attacker-controlled.  If the
>> parent zone is unsigned, I think opportunistic privacy is likely the best
>> we can offer.
>>
>> I'm not sure what you mean by control the name here.  To save me tilting
>> at strawmen, would you mind elaborating?
>>
>
> Ben,
>
> Is what you're saying here that .com provides the NS record for
> example.com and that may not itself be example.com, but instead
> ns.server.invalid, and therefore if you can't trust .com then it doesn't
> matter if ns.server.invalid has a WebPKI cert?
>
> -Ekr
>
>
(Apologies in advance for "DNS-splaining" this, but I'd rather do that than
assume knowledge of some tid-bit.)

I am neither Ben nor Ted, but I think I may get the gist of the conundrum
that exists due the "unsigned delegation" (which was labeled "unsigned
child zone", but can even be the case if the child zone is signed but not
securely delegated.)

The term for the child zone or any of the child's descendants, if any are
signed, is an "island of security". That refers to a sub-tree of DNS which
contiguous and where every delegation in that tree is signed, and every
other record type is signed.

What the problem is concerned with, is that the unsigned delegation creates
a gap in the security coverage at the child, where the authoritative data
for the child zone is not DNSSEC signed, and therefore potentially
vulnerable to "cache poisoning" attacks.

And a successful cache poisoning turns an otherwise benign record into an
"attacker controlled" record.

The (literal) key to preventing this, is to put all of the relevant
components under a signed parent, where that signed parent is one such
"island of security".  That "island parent" would be DNSSEC signed, and the
secure entry to that zone (the zone's KSK hash) would be the "trust anchor"
for everything below it.

Here are some example "meat" of how this might look:
com has a secure delegation to example.com, with NS of ns.server.example.net
(out of bailiwick for example.com to avoid any short cuts).
com has the corresponding DS record for example.com, which matches the
DNSKEY at the apex of the example.com zone.
example.com is a signed zone.
internal.example.com is an unsigned delegation; it has the NS record
pointing to the appropriate server for internal.example.com.
example.com does NOT have a corresponding DS record since
internal.example.com is an insecure delegation.

HOWEVER, it is entirely possible that internal.example.com is the top of
the internal-only "island of security", and has DNSKEY records etc.
(Even if there is a level of totally unsigned DNS between the signed parent
and for example the signed grandchild, the installation of the trust anchor
of the grandchild creates the necessary element for DNSSEC validation of
anything in that 

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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 usage are you thinking of, in RFC 6698 terms?
>
> Generally, I think TLSA-like authentication rooted in DNSSEC validation is
> fine.  But I remain pretty much of the opinion that if you get a
> certificate via that method that is "wrong" for values of wrong like
> "presented the wrong IP address or name in the cert"  or "fails DNSSEC
> validation" then you should do more than log the error.
>
> I also would like to point out that there are cases where you might have
> an authoritative server responding to recursive resolvers where there is a
> root of trust between them but where DNSSEC may not be validated:  split
> DNS.  Imagine for a moment that enterprise.example has a hierarchy that
> includes FQDNs like hostname.campus..internal.enterprise.example .  Each
> campus has its own recursive resolver, but they all talk to nameservers
> like ns.internal.enterprise.example.  In cases like those, the desire of
> the enterprise to not show its internal structures may mean that they do
> not wish to use DNSSEC to secure anything in internal, but they likely have
> a shared root of trust between the recursive resolvers and the
> authoritative server.
>
>
I think that is a very important use case, and also a good one to
illustrate the differences between the PKI model and the DNSSEC model.

PKI requires CRL/OCSP to handle any key problems or certificate revocation
or anything...
DNSSEC revocation can be done via DNS very quickly/scalably, although it
does also mean temporary loss of service if the new keys aren't also
available simultaneously. (That points to good BCP documents on managing
stuff.)

Distributing a localized DNS trust anchor is fairly straightforward, and I
have used such trust anchors previously in those environments. They work
exactly like you would expect. (At least for unbound, that is.)

Scaling for campuses works very well when you delegate from the signed
parental zone, and distribute the parental zone's trust anchor. Same model
as root DNSSEC trust anchor, different starting point.

Brian


> Put another way, I think you may need to support authentication using PKI
> trust anchors as well.
>
>  regards,
>
> Ted
>
> On Tue, Oct 29, 2019 at 12:01 PM Ted Hardie  wrote:
>>
>>> Hi Paul,
>>>
>>> On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman 
>>> wrote:
>>>
 On 10/29/19 8:02 AM, Ted Hardie wrote:
 > To be sure I understand you correctly, in the second case, the
 connection would be made to some IP address (e.g. NASA's 198.116.4.181).
 The recursive resolver logs the details of the certificate, but it
 continues with the connection even if the CA NASA uses for the certificate
 is not known to the resolver?  What does it do in the face of other
 certificate errors like expired certificates or certificates presenting a
 different name?

 It continues. This is exactly how opportunistic encryption is defined.


>>> Just to be clear, it's my experience that accepting self-signed
>>> certificates from peers does not equate to accepting certificate errors.
>>> The situation in which you set up a connection to n.n.n.n and get a self
>>> signed certificate saying "example.com" and when you set up a
>>> connection to n.n.n.n expecting "example.com" and get a cert back for
>>> "accident.example" are pretty distinguishable. I would expect some
>>> configurations to accept the first without issue; I find accepting the
>>> second deeply odd.
>>>
>>>
 > I have to say that I'm pretty surprised by the idea that TLS in this
 context should behave any differently than TLS in application layer
 contexts, and I'm a little concerned about having configuration options for
 this that amount to "ignore errors of types $FOO".

 TLS in application layers can specify that opportunistic encryption,
 yes?


>>> I think you are using "opportunistic encryption" to mean something
>>> different from what I mean by it.  What I mean by it is "use it when you
>>> can, even if you don't know in advance you can".  Testing for DoT before
>>> using a DNS resolver on UDP 53 and using it if you find it is
>>> "opportunistic encryption", for example.
>>>
>>>
 >  Accepting self-signed certificates is a known configuration, so I
 get that, but if someone has configured roots of trust, accepting other
 certificates outside the roots of trust in the configuration is pretty odd
 practice.

 Do you feel that there is a requirement that all recursive resolvers
 use the same set of trust anchors?
>>>
>>>
>>> No.
>>>
>>>
 If not, and if you are against the use of opportunistic encryption in
 this case,
>>>
>>>
>>> See above.  I don't think 

Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

[Brian Dickson]

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 wrote:
> >>
> https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/
> >>
> >> On 9/25/19 10:45 AM, Brian Haberman wrote:
> >>> All,
> >>>   We are going to hold a DPRIVE virtual interim meeting on Oct.
> 29th
> >>> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items are:
> >>>
> >>> - Review updates to the BCP based on WGLC comments,
> >>> - Review updates to 7626bis based on WGLC comments,
> >>> - Discuss recursive-to-authoritative requirements (-00 draft
> forthcoming).
> >
> > Will we be able to review the forthcoming recursive-to-authoritative
> requirements draft before the interim meeting?
>
> I have asked the authors to post either a -00 draft or a doc on GitHub
> before the interim.
>
> Brian
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Brian Dickson]

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 enable all forms of certificate issuance (public CA or not) and
validation type (cert chain or end entity) workable for doing certificate
validation.

I think this means that if both parties follow the recommended practice,
that even self-signed certs can be validated through the DNSSEC validation
plus the TLSA validation mechanisms.
The only reliance would be on the DNSSEC root trust anchor. That is
mandated when DANE is used, so it can be relied upon for all
implementations that follow the recommendations.
(Root trust anchor algorithms will always be a long-term thing to be
concerned about, but that is really a global issue for DNSSEC and
validating resolvers, not specific to this particular use.)

Brian

On Tue, Oct 29, 2019 at 9:01 AM Ted Hardie  wrote:

> Hi Paul,
>
> On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman 
> wrote:
>
>> On 10/29/19 8:02 AM, Ted Hardie wrote:
>> > To be sure I understand you correctly, in the second case, the
>> connection would be made to some IP address (e.g. NASA's 198.116.4.181).
>> The recursive resolver logs the details of the certificate, but it
>> continues with the connection even if the CA NASA uses for the certificate
>> is not known to the resolver?  What does it do in the face of other
>> certificate errors like expired certificates or certificates presenting a
>> different name?
>>
>> It continues. This is exactly how opportunistic encryption is defined.
>>
>>
> Just to be clear, it's my experience that accepting self-signed
> certificates from peers does not equate to accepting certificate errors.
> The situation in which you set up a connection to n.n.n.n and get a self
> signed certificate saying "example.com" and when you set up a connection
> to n.n.n.n expecting "example.com" and get a cert back for
> "accident.example" are pretty distinguishable. I would expect some
> configurations to accept the first without issue; I find accepting the
> second deeply odd.
>
>
>> > I have to say that I'm pretty surprised by the idea that TLS in this
>> context should behave any differently than TLS in application layer
>> contexts, and I'm a little concerned about having configuration options for
>> this that amount to "ignore errors of types $FOO".
>>
>> TLS in application layers can specify that opportunistic encryption, yes?
>>
>>
> I think you are using "opportunistic encryption" to mean something
> different from what I mean by it.  What I mean by it is "use it when you
> can, even if you don't know in advance you can".  Testing for DoT before
> using a DNS resolver on UDP 53 and using it if you find it is
> "opportunistic encryption", for example.
>
>
>> >  Accepting self-signed certificates is a known configuration, so I get
>> that, but if someone has configured roots of trust, accepting other
>> certificates outside the roots of trust in the configuration is pretty odd
>> practice.
>>
>> Do you feel that there is a requirement that all recursive resolvers use
>> the same set of trust anchors?
>
>
> No.
>
>
>> If not, and if you are against the use of opportunistic encryption in
>> this case,
>
>
> See above.  I don't think I'm against opportunistic encryption.  I think
> I'm against starting to exchange traffic over a TLS connection with an
> identifiable error.  There are degrees there, obviously.  Some folks would
> say an expired but correct certificate should be logged but accepted, but a
> flat out "wrong name presented" would likely get different treatment.
>
> who will decide what set of trust anchors all resolvers in all
>> jurisdictions will use?
>>
>>
> Everyone will decide who they accept?  That's how the WebPKI works, for
> all its shuffling glory, and with ACME/Let's Encrypt it has gotten very
> easy to get a certificate that will often be accepted.
>
> Just my two cents,
>
> Ted
>
> --Paul Hoffman
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

[Brian Dickson]

t;cache refresh" distinction.

This might be where the EDNS signaling available directly between the
recursive and authoritative, would allow the authoritative server to make
the informed decision to reply with UDP instead of over the ADoT
connection, if/when it experiences significantly increased load. The
recursive could always try to use ADoT, but get signal(s) from the
authority server to limit ADoT to "cold cache" queries only in response to
load problems.

Finally, I'd like to announce the following:
*GoDaddy now has four ADoT servers in its OTE environment.*
They are ns01/ns02, and pdns01/pdns02 in ote.domaincontrol.com, with
domains dnsczar.com and sheldns.com on those respective nameserver pairs.
The TLS certificate names match the NS names for those domains.
The test domains are also DNSSEC signed.
(The domaincontrol.com zone is not yet signed, so no DANE/TLSA for the
certs just yet.)

Please feel free to test against those domains, and feedback on that
testing 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 Dickson

On Mon, Oct 28, 2019 at 3:24 AM Alexander Mayrhofer <
alex.mayrhofer.i...@gmail.com> wrote:

> I've just posted the -00 individual submission version:
>
> https://tools.ietf.org/id/draft-lmo-dprive-phase2-requirements-00.txt
>
> Sorry for the delay, but i hope that people still have some time to
> look through that draft.
>
> best,
> Alex
>
> On Fri, Oct 25, 2019 at 8:59 PM Livingood, Jason
>  wrote:
> >
> > I just submitted my final changes to Benno and Alex and put the ball in
> their court to send something over the weekend or on Monday morning in
> Austria or the Netherlands. It is a very early -00 and so intended to
> mostly spur WG discussion.
> >
> > Jason
> >
> > On 10/25/19, 11:05 AM, "dns-privacy on behalf of Brian Haberman" <
> dns-privacy-boun...@ietf.org on behalf of br...@innovationslab.net> wrote:
> >
> > Hi Paul,
> >
> > On 10/25/19 10:27 AM, Paul Hoffman wrote:
> > > On 10/25/19 6:25 AM, Brian Haberman wrote:
> > >>
> https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/
> > >>
> > >> On 9/25/19 10:45 AM, Brian Haberman wrote:
> > >>> All,
> > >>>   We are going to hold a DPRIVE virtual interim meeting on
> Oct. 29th
> > >>> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items
> are:
> > >>>
> > >>> - Review updates to the BCP based on WGLC comments,
> > >>> - Review updates to 7626bis based on WGLC comments,
> > >>> - Discuss recursive-to-authoritative requirements (-00 draft
> forthcoming).
> > >
> > > Will we be able to review the forthcoming
> recursive-to-authoritative requirements draft before the interim meeting?
> >
> > I have asked the authors to post either a -00 draft or a doc on
> GitHub
> > before the interim.
> >
> > Brian
> >
> >
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

[Brian Dickson]

Top reply to my own post, sorry.

Even if *THIS* document is in DPRIVE (which I think it should be), it does
not necessarily imply that ADoT development itself has to be done in
DPRIVE; I think where ADoT development actually happens is a separate
question/discussion.

Brian

On Wed, Aug 28, 2019 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:
>>
>> https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DPRIVE, and comment to the list, clearly stating your view.
>>
>>
> I am in favor of adoption of this draft by DPRIVE.
>
> My view is as follows:
> - DNS is an ecosystem which by definition requires interoperability.
> - Authority operators are a distinct subset of the participants in the DNS
> ecosystem
> - Authority operators of registered domains (as distinct from
> delegation-only domains) have operational concerns (including scaling
> issues and performance issues) that are appropriate to consider BEFORE the
> development of ADoT itself.
> - I.e. The draft should be input to the ADoT development process, similar
> to a requirements document.
> - Doing development of ADoT without this would be another example of IETF
> "paper engineering", which while attractive to some participants, is very
> harmful to reasonably mature ecosystems. (The "paper engineering" practice
> is harmful even in green-field, IMHO.)
> - Operational considerations != deployment guidelines. This is basically a
> pre-emptive feedback to the standards design, based on known issues that
> will affect any flavor of ADoT, no matter what it looks like.
> - Deployment guidelines to operators would follow implementations, which
> would follow standard development, which *should* take into consideration a
> variety of factors, which this document covers.
> - There is work to be done on the document, but it is a great start.
>
>
>> Please also indicate if you are willing 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 call for adoption ends: 28 August 2019
>>
>> Thanks,
>> Brian & Tim
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

[Brian Dickson]

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:
> https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/
>
> Please review this draft to see if you think it is suitable for adoption
> by DPRIVE, and comment to the list, clearly stating your view.
>
>
I am in favor of adoption of this draft by DPRIVE.

My view is as follows:
- DNS is an ecosystem which by definition requires interoperability.
- Authority operators are a distinct subset of the participants in the DNS
ecosystem
- Authority operators of registered domains (as distinct from
delegation-only domains) have operational concerns (including scaling
issues and performance issues) that are appropriate to consider BEFORE the
development of ADoT itself.
- I.e. The draft should be input to the ADoT development process, similar
to a requirements document.
- Doing development of ADoT without this would be another example of IETF
"paper engineering", which while attractive to some participants, is very
harmful to reasonably mature ecosystems. (The "paper engineering" practice
is harmful even in green-field, IMHO.)
- Operational considerations != deployment guidelines. This is basically a
pre-emptive feedback to the standards design, based on known issues that
will affect any flavor of ADoT, no matter what it looks like.
- Deployment guidelines to operators would follow implementations, which
would follow standard development, which *should* take into consideration a
variety of factors, which this document covers.
- There is work to be done on the document, but it is a great start.


> Please also indicate if you are willing 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 call for adoption ends: 28 August 2019
>
> Thanks,
> Brian & Tim
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Brian Dickson]

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 starting point is not accurate or correct, IMHO, at least for
scope, or whether/how any given DoH implementation interacts with the
user(s).

Jason was suggesting that there are (or at least may be) multiple levels of
ISP and/or Enterprise and/or controlled (parental) stuff; those might nest
with no "naked" root (unfiltered) depending on the particular ISP, or
mandated legal thing, or "public" offering doing anything questionable.

Notwithstanding any desire to have users use DoH to arbitrary endpoints, in
some environments (enterprises) or regulatory environments (western
countries which have different restrictions on legal contracts and user
acceptance stuff.

This means that it is NOT the case that EVERY potential deployment
environment is going to be compatible with a DoH client that bypasses any
controls that might be present, without violating laws, contracts, or other
controlling limitations.

The starting place for the conversation needs to acknowledge this, and
accommodate it. It is entirely possible that a DoH client that doesn't do a
minimum level of getting user acknowledgement before violating policies,
laws, or contracts, might itself be illegal in some jurisdictions
(jurisdictions that could include some US states, some western countries,
some larger entities like EU, etc.).

This is not to say it isn't going to be the case that users can't "force"
some kind of DoH-like thing, only that it needs to be under some kind of
affirmative control, where a user makes an informed decision with some kind
of explicit understanding/acknowledgement.

It probably would be advisable for DoH implementations to NOT make that
explicit acknowledgement externally visible to e.g. authoritarian regimes,
but that is stuff to discuss/explore, i.e. it's an open question.

It would be very helpful for moving the conversation forward if the DoH
proponents could start with acknowledging this set of legal/contractual
issues, and that any kind of DoH client that just automatically does stuff
that bypasses any mechanisms to restrict DNS, likely isn't known to be
compliant with all laws in all jurisdiction (and probably would be
problematic, at a minimum).

Brian
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients

[Brian Dickson]

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
> > achieved consensus. (See RFC7626) (*)
>
> i have no qualms about confidentiality, for traffic allowed by a network
> operator. it's the inability to interefere (as called for in RFC 8484) and
> not
> the inability to observe (as called for in RFC 7626) that's at issue here.
>
> > DoT is one way to tackle those problems. DoH is another.
>
> DoT does not intend to place itself beyond interference by on-path
> entities,
> and as such, my choice as a network operator is either to allow it through
> even though i can't see the contents, or disallow it. and that's all fine.
>
>
I think there is a way to use technical design(s) to split hairs, i.e. I
think the side meeting
has the possibility of bearing fruit which is palatable enough for all
parties.

The crux of the problem is how to determine if the network operator is
truly hostile (GFC),
or merely restrictive (Paul's network, Paul's rules.)

Suppose the client signaled a desire to use a particular DoH operator.
The network could respond with, "No", or "Yes", or "Yes, but I want to
inspect your DNS traffic",
or "No, but I'll place you logically outside my network, and enable the
isolated bubble you are in to do what you want."
The client could treat "No" as hostile, and do something appropriate for
being behind the GFC.
The client could treat the "Yes, but" as a reason to then ask for the
"bubble" treatment.
If the client is offered and accepts, or requests and is permitted, the
"bubble" treatment, there is no need to go hostile.
In "bubble", the client would not be able to interact with any local
resources, in effect being in a non-split-mode VPN to the outside world.

There is really nothing that would stop a non-compliant client (or malware)
from choosing the "hostile" mode.
However, if "bubble" is available, I don't see why that would not be
acceptable for any client that isn't malicious.

Does "bubble" (and the signaling required) seem like a promising compromise?
(Presuming the operator can still refuse "bubble" requests, of course,
perhaps with a polite message denying the request with an explanation.)

(Also, I would expect the MDM thing can be reduced to whether client(s) are
allowed to go hostile or do "bubble" mode.)

Brian

Brian


> DoH intends "to prevent on-path interference with DNS operations", and
> that's
> well beyond the remit of RFC 7626, and is therefore not spoken to one way
> or
> another by IETF consensus. i do not believe that a non-interference
> objective
> would reach broader IETF consensus. perhaps we can test that one day.
>
> vixie
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

[Brian Dickson]

(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 conditions/circumstances), e.g. with
respect to opt-in vs opt-out.

E.g. If the local network operator is giving out addresses using DHCP or
the equivalent, then the presence/absence of DNS options in the answers,
should to some degree dictate (permitted) behavior.
And similarly, having some kind of DoH signaling incorporated in the DHCP
options, would be a sensible analogous mechanism.
E.g. "I will allow you to request DoH using providers X, Y, and Z, but
insist on being a MITM for those connections", or "Go ahead and do DoH to
any of these providers X, Y, Z, but no others", or "DoH is prohibited here,
use DNS", or "You can use DoT to these providers, DoH with me as MITM, or
this DNS resolver, but you can't run your own resolver".

Not sure what other mechanisms might be worth considering as alternatives
(dns-sd of some flavor)...

The mechanisms definitely to be a lot cleaner, more transparent, and
configurable, for both clients, network operators, and possibly DoT/DoH
operators.

(Did we learn nothing from the dial-up ISP early days, with mailing out
physical CD ROMs with phone numbers in lists and browsers included?)

Brian

On Sun, Mar 10, 2019 at 11:17 PM Paul Vixie  wrote:

>
>
> Christian Huitema wrote on 2019-03-10 23:05:
> > On 3/10/2019 10:24 PM, Paul Vixie wrote:
> >
> >> if you are using my network, then it makes no difference which of us
> >> bought you that laptop. you will use the RDNS i allow you to use. RDNS
> >> is part of the control plane, and i use it for both monitoring and
> >> control. sometimes that's so that i can see malware beacon to its C
> >> sometimes that's so that i can institute parental controls.
> >>
> >> if you don't like my rules, you should vote with your feet, and not
> >> visit me. because that is the only choice you will have. (yes, i will
> >> be part of a major new project to identify and block all DoH services,
> >> so that behavioural security policies can still work, because you may
> >> have noticed that the internet has never become MORE secure from new
> >> tech, but it occasionally becomes LESS secure more slowly because of
> >> policy.)
> >
> >
> > "Use a VPN, or use the local defaults".
>
> that is not what i said.
>
> > Well, there are plenty of
> > in-between.
>
> yes, and i gave examples.
>
> see above.
>
> > You claim the right to impose your rules, because it is "your network".
> > Yet you have to define ownership. You are providing network services
> > under some contractual terms. There are cases where an imperial network
> > can dictate those terms, but there are also many cases in which the
> > contractual power of the network is limited  -- thinks like fair access,
> > network neutrality, etc. Just claiming an empire does not automatically
> > make you the emperor.
>
> my network, my rules. your provider's network, their rules. they are
> more likely to have to follow their government's laws of commerce and
> privacy than i am likely to have to follow mine. but if the rules your
> network operator can make allow you to do what you want, use that
> network. that's invariant, for all networks, and for all instances of you.
>
> --
> P Vixie
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-05.txt

[Brian Dickson]

Sorry to be commenting so late in the process...

Was the strategy of "MTU(-ish) maximum padding policy" ever suggested,
possibly as an alternative to Maximum Padding Policy?

IMHO, there are signifiant benefits, even beyond privacy:

   - It addresses the issues on Random that Eric R raises
   - It doesn't fragment (at least locally and/or if "Internet MTU"
   value(s) are used, like 1492 or 1472 or 1452 rather than 1500 (takes into
   account expectations on use of MPLS and/or L2 encapsulation in the middle
   while still using "maximum-ish" padding,  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

On Fri, Apr 13, 2018 at 3:47 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
>
> Title   : Padding Policy for EDNS(0)
> Author  : Alexander Mayrhofer
> Filename: draft-ietf-dprive-padding-policy-05.txt
> Pages   : 10
> Date: 2018-04-13
>
> Abstract:
>RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify
>the actual padding length for specific applications.  This memo lists
>the possible options ("Padding Policies"), discusses implications of
>each of these options, and provides a recommended (experimental)
>option.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dprive-padding-policy-05
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-padding-policy-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-padding-policy-05
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy