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

[Ted Hardie]

I support adoption and I would be willing to review and contribute text.

Ted

On Wed, Apr 8, 2020 at 9:41 AM Tim Wicinski  wrote:

>
> This starts a Call for Adoption for draft-huitema-dprive-dnsoquic
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-huitema-dprive-dnsoquic/
>
> Please review this draft to see if you think it is suitable for adoption
> by DPRIVE, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 22 April 2020
>
> Thanks,
> tim/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

[Ted Hardie]

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.

regards,

Ted Hardie



> —--
> Ralf Weber
>
> ___
> 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] FW: New Version Notification for draft-mglt-dprive-dns-uri-00.txt

[Ted Hardie]

Hi Daniel,

On Thu, Mar 19, 2020 at 11:16 AM Daniel Migault  wrote:

> Hi Ted,
>
>
>
> Thanks for the feed back. The dns uri scheme has the port optional and
> provides port flexibility.
>

I believe the port is optional to include in any URI, but I believe support
for a port is mandatory to implement.  Are you aware of implementations
that don't implement it?

If we are using the port as an indication of the transport protocol, we are
> losing this flexibility. A consequence is that is it would prevent using
> other ports than non standard port.
>

I think it means there's a different trade-off.  If you use an existing
port in a non-standard way, this will fail (and that's pretty correct
behavior in the face of squatting).  If you use a non-standard port, you
can use this mechanism to specify the port.  The client would then need to
attempt the connections with its preferred mechanism (for the TLS ones,
using ALPN) and then decide whether to fall back to less-preferred methods
if those are not available.  I would strongly urge that preference go from
most confidential transport to less confidential transports, but that would
ultimately be a client decision.

At least from my point of view, what you appear to want is configuration
protocol, but neither what you specified nor the original is a DNS client
configuration protocol.  They primarily provide a reference to specific
resource record data in the DNS, and this form:

dns:www.example.com?clAsS=IN;tYpE=A

looks like it ought to be the most common; it tells you the reference to a
specific RR, without requiring you to get it from anywhere in particular.
That works with whatever resolver you have configured, at least in the
common case.

The extended forms, which name or provide an address for a specific
resolver are useful (e.g. for split DNS), but I think creating a bunch of
different URI schemes to extend that to specify a protocol is more harmful
than helpful, as you then have an equivalence problem.  Are
dot://server.example:2836/:www.example.com?clAsS=IN;tYpE=A and dns:
www.example.com?clAsS=IN;tYpE=A presumed to be equivalent or not?

What that suggests is, if you really believe the trade-off to focus on
specific servers and non-standard ports is critical, that you should mint a
single URI scheme for the purpose, with a mandatory paramater that lists
the transports .  I would personally still feel that was heading this in
the wrong direction, but it would avoid some of the worst questions about
equivalence.

regards,

Ted



> My impression also is that some people are willing to deploy DoT or DoH on
> non standard port, thought I might wrong.
>
>
>
> For DoH, my understanding is that URI is formed according to the URI
> template. I think that being able to provide the path could be useful
> especially when different paths will be associated to different service.
> Maybe additional element may also be useful to add.  I do not think the
> current dns scheme enables this and I would be happy to have your thoughts
> on it as I am not particularly familiar with uri template.
>
>
>
> Basically using the old dns uri, this would be something like:
>
> dns://host.example:443/dns-with-parental-protection/
> www.example.org?clAsS=IN;tYpE=A
>
> dns://host.example:443/dns-without-filtering/
> www.example.org?clAsS=IN;tYpE=A
>
>
>
> Yours,
>
> Daniel
>
> On Thu, Mar 19, 2020 at 1:44 PM Ted Hardie  wrote:
>
>> Hi Daniel,
>>
>> I'm not sure I understand the need here.  The existing DNS URI scheme
>> uses the standard authority semantics, so it permits a port.   It seems
>> like using that gives you the same semantics as these additional schemes.
>> That is:
>>
>> dns://host.example:53/www.example.org.?clAsS=IN;tYpE=A
>>
>> dns://host.example:853/www.example.org.?clAsS=IN;tYpE=A
>>
>> dns://host.example:443/www.example.org.?clAsS=IN;tYpE=A
>>
>> seem to handle the cases where you need to specifically call out DNS is
>> being served over traditional transports (UDP and TCP over 53), DoT, and
>> DoH.
>>
>> What am I missing here?
>>
>> thanks,
>>
>> Ted
>>
>> On Thu, Mar 19, 2020 at 9:52 AM Daniel Migault > 40ericsson@dmarc.ietf.org> wrote:
>>
>>> Hi,
>>>
>>> Please find a draft describes URIs that describes the DNS resource being
>>> accessed through DNS53, DoT and DoH.
>>>
>>> Any comment / suggestions are welcome.
>>>
>>> Yours,
>>> Daniel
>>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org 
>>> Sent: mercredi 18 mars 2020 22:57
>>> To: Daniel Migault 
>>> Subject: New Version Notification for draft-mglt-dprive-dns-uri-00.txt
>>

Re: [dns-privacy] FW: New Version Notification for draft-mglt-dprive-dns-uri-00.txt

[Ted Hardie]

Hi Daniel,

I'm not sure I understand the need here.  The existing DNS URI scheme uses
the standard authority semantics, so it permits a port.   It seems like
using that gives you the same semantics as these additional schemes.  That
is:

dns://host.example:53/www.example.org.?clAsS=IN;tYpE=A

dns://host.example:853/www.example.org.?clAsS=IN;tYpE=A

dns://host.example:443/www.example.org.?clAsS=IN;tYpE=A

seem to handle the cases where you need to specifically call out DNS is
being served over traditional transports (UDP and TCP over 53), DoT, and
DoH.

What am I missing here?

thanks,

Ted

On Thu, Mar 19, 2020 at 9:52 AM Daniel Migault  wrote:

> Hi,
>
> Please find a draft describes URIs that describes the DNS resource being
> accessed through DNS53, DoT and DoH.
>
> Any comment / suggestions are welcome.
>
> Yours,
> Daniel
>
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: mercredi 18 mars 2020 22:57
> To: Daniel Migault 
> Subject: New Version Notification for draft-mglt-dprive-dns-uri-00.txt
>
>
> A new version of I-D, draft-mglt-dprive-dns-uri-00.txt has been
> successfully submitted by Daniel Migault and posted to the IETF repository.
>
> Name:   draft-mglt-dprive-dns-uri
> Revision:   00
> Title:  Domain Name System Uniform Resource Identifiers for DNS
> over HTTPS and DNS over TLS
> Document date:  2020-03-18
> Group:  Individual Submission
> Pages:  7
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-dprive-dns-uri-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mglt-dprive-dns-uri/
> Htmlized:   https://tools.ietf.org/html/draft-mglt-dprive-dns-uri-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mglt-dprive-dns-uri
>
>
> Abstract:
>Today DNS resources may also be accessed using multiple transport
>which includes DNS over UDP/TCP port 53 [RFC1034],[RFC1035].  DNS
>over TLS [RFC7858] or DNS over HTTPS [RFC8484].  This document
>describes URIs that describes the DNS resource as well as indicate
>the transport to access the resource.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
> ___
> 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] Discovery of DNS over (not 53) and ALPN

[Ted Hardie]

So this came up in an another thread, but it probably needs a separate
topic.

The point being made was:

We really need to figure out how to do DoWhatever discovery, preferably
> better than probe ports on the same IP as the port 53 server.
>

I think one critical question is how discovery of DoT and DoH (and later
entrants)  servers is related to the discovery of port 53 servers.  One
possibility here, if we do define ALPN tokens for each of these, is to
combine that token with the base discovery methods.  So, DHCPv4 Option 6
(or DHCPv6 option 23) gives you the IP address of the server, and a new
DNS-ALPN option code gives you the ALPN(s), from which you derive the port.

If the DNS-ALPN option code is absent, go to port 53.  If there is one
present, it is a list, like the ALPN next protocol list, of the tokens
corresponding to the list the server supports.  This implies that you would
need an ALPN token for DoT port 853 to be available and distinct from DoT
port 443.

Router advertisements are a little trickier.  If someone is currently using
RFC 8106 style advertisements, I think it would be cleaner to have those
still present and a new option for DNS-over-not-53 options.  That could
still leverage the ALPN list as a way of making that a single option
(rather than a bunch of separate announcements).

There are clearly operational environments that wouldn't follow this (those
that use the URI template in RFC 8484, for example), but something that
allows you to signal them together does seem useful.

Note that this approach means that if you have a client that supports DNS
over 53 and doesn't understand the ALPN token in the new option, you can
run into a corner case.  If the network does not support DNS over 53, the
client will fail to see the alternatives to port 53.  It would then have to
interpret an ICMP destination unreachable (presuming that gets through).

I'm not an expert on either DHCP or RA, of course, so I may have this wrong
way around.

regards,

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

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

[Ted Hardie]

In-line.

On Wed, Nov 6, 2019 at 9:05 AM Brian Dickson 
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.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.

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] Threat Model

[Ted Hardie]

(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.


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


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.


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.

regards,

Ted
___
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?

[Ted Hardie]

Hi Brian,

On Fri, Nov 1, 2019 at 8:35 AM Brian Dickson 
wrote:

>
>1. The operational cost of serving ADoT answers is prohibitive, due to
>a number of factors:
>   1. Maintaining state, for TCP and for TLS
>
>
>1. Set-up overhead for TLS
>   2. Ongoing encryption of traffic after set-up, e.g. AES
>   computational cost, vs "copy bytes" (possible with DMA and no CPU)
>
> You do realize that exactly this set of arguments has been used in the
past, to say that web servers would not be able to switch to TLS by
default?  And yet, the queries per second for popular sites served over TLS
keeps going up and up, and the elastic compute and delivery of services
means that similar methods are available at relatively low incremental
costs?

For an authoritative serving a typical zone (an enterprise, a modest web
site, a government agency), none of these incremental costs matter, given
the expected query load.  They matter for TLDs and popular second level
zones like co.uk, and we should care as a result.  But there is no need to
despair.  If you are willing to see DNS data delivery as a standard
application scaling question, rather than as a special case, there are a
lot of tools available already.


>1. Deployment of ADoT without providing means for managing these costs
>   is highly unlikely to happen
>   2. Developing means to manage ADoT costs (in the standards, and in
>   implementations) is highly non-trivial.
>
> There's a lot of work to crib from, and there are also, bluntly, people
who can sell you this capacity if you don't want to care.


>1. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
>(Cheap, easy, fast, choose two, currently zero are available to choose.)
>
> It's our job to make this better. Bold-faced assertions which don't look
at wider contexts aren't much help there, I'm afraid.

regards,

Ted



> 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] ADoT deployment at the root

[Ted Hardie]

On Thu, Oct 31, 2019 at 12:06 PM Jim Reid  wrote:

>
> There are gazillions of layer-9+ problems around the introduction of new
> or different distribution mechanisms at the root for serving root zone
> data. Not least of these are the interminable ICANN consultations that
> inevitably have to take place for anything remotely related to the root.
>
> Some of those problems will also apply to ADoT deployment at "busy" TLDs
> and their DNS service providers.
>
>
I think the point John Levine was making earlier relates to this, though.
If the root zone is signed, it is small enough to keep a copy locally in
any reasonable cache.  That means many caching resolvers can avoid using
DoT on queries routed to the root by using AXFR instead,  to the servers
mentioned in https://www.dns.icann.org/services/axfr/ or similar servers
hosted elsewhere.  Asking that those AXFR-suitable servers support DoT
seems a much more tractable proposition and it results in the right thing.

I may have misunderstood John, of course, but that's the point of what I
understood him to be saying.

regards,

Ted
___
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?

[Ted Hardie]

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
<https://engineering.fb.com/security/dns-over-tls/> 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?

thanks,

Ted

 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 roo

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

[Ted Hardie]

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.

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 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
>&

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

[Ted Hardie]

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

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

[Ted Hardie]

Hi Paul,

On Tue, Oct 29, 2019 at 7:50 AM Paul Hoffman  wrote:

> Greetings again. I was surprised, but happy, to not see a requirement in
> the list for authentication of servers in the list. However, I suspect that
> this might have been an oversight, and the endless debate on authentication
> requirements will start as soon as there is a proposed protocol document.
>
> My preference would be that the core requirement is that ADoT servers use
> either IP address or DNS name authentication in their certificates, but
> that the certificates can be issued by any CA, including being self-issued.
> The core requirement could also go on to say that resolvers be able to
> authenticate servers for logging purposes, but not be required to break TLS
> connections if the server's identity cannot be authenticated against the
> resolver's set of trust anchors.
>
>
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?

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".  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.

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

Re: [dns-privacy] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Ted Hardie]

On Mon, Mar 11, 2019 at 10:13 AM Stephane Bortzmeyer 
wrote:

> On Mon, Mar 11, 2019 at 10:06:21AM -0700,
>  Ted Hardie  wrote
>  a message of 76 lines which said:
>
> > This conflicts with SECDISPATCH, which will have a pretty serious impact
> on
> > who might attend.  Scheduling these things is very hard, obviously. Given
> > this topic, you may have to move outside the normal agenda time to get a
> > reasonable shot at avoiding conflict.
>
> I avoided conflicts with doh, dprive, dnsop and hrpc but avoiding all
> conflicts is close-to-impossible. In the evening, people have
> meetings, too.
>
> I admit I'm not sure that Secdispatch is so important here. The
> subject of the side meeting is not security-specific.
>

It is certainly not only about security, but there are several important
security trade-offs in play with these choices.  Secdispatch pulls pretty
much the entire Security Area, and a conflict seems to me personally very
unfortunate in its scope.

regards,

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

Re: [dns-privacy] Still interested in recursive-to-authoritative

[Ted Hardie]

On Fri, May 25, 2018 at 8:08 AM, Sara Dickinson  wrote:

>
>
> >
> > The happy eyeballs reference looks to be the right thing to do.
>
> Section 3: I’d like to see a bit more discussion around this proposal:
> "A resolver working in opportunistic mode should try ports 53 and 853 in
> parallel.”
>
>
In addition to the privacy concern that Sara makes below (and with which I
agree), it's actually not what the current specification of Happy Eyballs
says.  RFC 8305 says instead:

   Once the list of addresses received up to this point has been
   constructed, the client will attempt to make connections.  In order
   to avoid unreasonable network load, connection attempts SHOULD NOT be
   made simultaneously.

Presuming we treat the "address" here as a tuple of IP address and port and
give a preference for 853 in the sorting algorithm, you'd end up starting
with it and then going to 53 only after the default delay expired.

I think that's better than concurrent attempts on several fronts.

regards,

Ted

> I see the obvious latency win here but the downside with this mode (as
> currently described) is that it _always_ leaks the query in cleartext so it
> seems to defeat the point of using TLS. Unless the should (SHOULD?) here is
> allowing for resolver behaviour where it has some cached knowledge of this
> authoritative's capabilities and so could choose to probe all addresses
> over 853 before falling back to 53? If so I think that should be spelled
> out more clearly.
>
> I’d always seen opportunistic as ‘try for the best but be willing to
> fallback to the worst case’ which isn’t exactly the same as ‘happy
> eyeballs’ which I see as try everything in parallel?
>
> >
> > The draft states:
> >
> >> If it is a concern that the same authoritative name servers are used
> >> for ordinary DNS and for encrypted DNS,
> >
> > I don't know that should be, but if so it probably should discuss why
> > some may find it to be a concern.
>
> Is this related to the monitoring/data retention/privacy policies by the
> operator?  In other words that the concern is they treat all the data as if
> it were unencrypted….
>
> >
> > I think we should discuss whether an EDNS option to signal a successful
> > authentication or failure really is out of scope, as the draft says.
>
> Interesting yes, but rogue or broken clients could easily send false
> responses so I’m unsure of how useful this is? What would the specific use
> case be?
>
>
> One other comment - in RFC8310 there is discussion of the possible attacks
> on meta queries (used here to obtain the TLSA records) - it seems the same
> concerns apply here too and should be mentioned in the Security
> Considerations?
>
> Regards
>
> Sara.
>
>
>
>
> ___
> 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] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt

[Ted Hardie]

On Wed, Jul 8, 2015 at 12:21 AM, Jiankang Yao ya...@cnnic.cn wrote:



 It's also not clear to me, given that the stub public key is sent in the
 query to the recursive resolver how you avoid an attacker standing up a
 back-to-back user agent which strips that option, substitutes its own
 public key, gets the data and then passes it on.  (It may be, of course,
 that this attack is out of scope).
 *[Jiankang Yao]*
  Yes, the attacker standing up a back-to-back user agent can strip that
 option, substitute its own public key, get the data and then pass it on.
  but I think that it should be no use because the attacker can not know
 the contents of the DNS packet send by the stub.

​I think I wasn't clear enough about the attack.  If the attacker strips
the option and sends it with its own public key​, it can decrypt the
response.  It can send its version in advance of sending the original
packet along, so it can see the response and potentially drop packets that
match some policy.  (If they are acceptable, it just sends the queued
packet along).  It can also be done along side the original packet, to
enable tracking without applying policy.  That's mildly detectable, since
the recursive resolver would see multiple queries, but it would be pretty
easy to obfuscate by generating new client public keys and varying the
query interval.

Does that make sense?

regards,

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

Re: [dns-privacy] DPRIVE over UDP or TCP

[Ted Hardie]

On Wed, Apr 22, 2015 at 10:15 AM, Dan Wing dw...@cisco.com wrote:

 During the DPRIVE meeting in Dallas, several questions came up about UDP
 versus TCP.  We had previously submitted a DNS over DTLS document which
 predated DPRIVE.  We re-submitted the document with a few edits and a
 filename that makes it easier to find,
 https://tools.ietf.org/html/draft-wing-dprive-dnsodtls, diffs at
 https://tools.ietf.org/rfcdiff?url1=draft-wing-dnsop-dnsodtls-01url2=draft-wing-dprive-dnsodtls-00

 The working group may want to consider the advantages of DNS over DTLS
 over UDP compared to using TCP:

  * No reliance on operating system support of TCP Fast Open [RFC7413] to
 achieve same number of round trips.
  * Avoidance of TCP's network head of line blocking.


​Just to confirm my understanding, with DTLS plus anycast, you'd have
similar issues for restart as TCP (state being associated with a single
endpoint, timeout required for flushing state).  Is that your thinking as
well?​

regards,

Ted



 -d


 ___
 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] The case for both ends of 'end-to-end'

[Ted Hardie]

On Tue, Oct 21, 2014 at 3:36 AM, Jay Daley j...@nzrs.net.nz wrote:


 On 21/10/2014, at 2:10 pm, Paul Vixie p...@redbarn.org wrote:

  it is that third option that should concern us -- i would like to see an
 XML schema for DNS data (similar to bortzmeyer's effort)


 Done:  http://tools.ietf.org/html/draft-daley-dnsxml-00

 and a URL schema for encoding DNS queries,


 What an interesting idea.


​Um, RFC 4501 created one; other than the existing erratum noting a typo in
the reference to RFC 3490, is there something wrong with it?

regards,

Ted​



 and we should move the stub-to-recursive data path to HTTPS. if XML loses
 this war that i'll suggest a RESTful/JSON API. ultimately we should connect
 to an HTTP listener and use a URL pattern like
 /dns/query/QNAME/QCLASS/QTYPE and get back an XML or a JSON blob.


 I prefer

 /query/QNAME.json?qtype=QTYPE
 /query/QNAME.json?qtype=QTYPEqclass=QCLASS
 /query/QNAME.xml

 But I suspect that needs a lot more thought.

 Jay

 TLS, with PFS, should protect the privacy of this data.

 in that sense i would be alarmed to hear a proposal that the DNS protocol
 itself should add features to support secrecy or privacy, because that
 problem can be solved in the transport, and because we need an HTTPS Web
 API to fix many other emergent and compelling problems in the
 stub-to-recursive layer.

 so, i don't understand why the IESG approved this working group, unless
 it's to rubber stamp what we already know, or to investigate things we
 already know should not be done.

 with that background, let me respond to hugo's note, on which he helpfully
 cc'd me.


 Hugo Maxwell Connery Monday, October 20, 2014 10:51 AM
 Hi,

 I am deeply supportive of the IETF's effort to address
 user privacy in all contexts. Pervasive monitoring
 is an attack, and I am grateful for the IETF acknowledging
 it as such.

 The core mission of DPRIVE is stated as confidentiality
 between DNS Clients and Iterative Resolvers with possible
 extension to end-to-end type scenarios. Clarifying as
 DPRIVE will address risks to end-users' privacy.


 i do not accept that redefinition as a clarification.


 I believe that an extended discussion of the area of
 consideration is worthwhile.

 The landscape could be classified into:

 A) An end-user running some application that needs DNS, and
 it (we hope) uses the stub resolver associated with the
 operating system. I group these as A.

 B) A calls some iterative resolver, B, which returns
 from cache or calls a collection of authoritative
 resolvers, C.

 C) The collection of authoritative resolvers.

 These can be all on different systems (normal) or even
 all collocated ($ dig localhost).

 One can insert encrypted networks between components, and
 those networks can handle all or some fraction of a client's
 traffic.

 As there is currently no provision for encrypting DNS
 traffic, all claims that it is solved, for 'A to B' or
 anywhere, by VPN or TOR (for example) are all false.


 i disagree. a client could have a policy that only an encrypted tunnel or
 negotiated IPSEC is acceptable, and return SERVFAIL if such is not
 available. some sensitive networks already work this way, so, i have
 witnessed and consulted on existence proofs of the statement you group into
 the set are all false.


 What they do is move the traffic to another end-point and
 provide anonymity in proportion to the volume of the community
 using the end-point. TOR is far superior to a VPN as its
 endpoint cannot know the source, by design.


 you're overstating the problem and then claiming there is no solution.
 that's a straw man fallacy.


 Providing a standard for encrypting 'A to B' would create
 a very similar situtation, where the privacy would really
 be based on anonymity. Only one person using the resolver?
 Then all the authoritative queries are generated by their
 queries. This would still be an improvement as the frequency
 of their queries would be unknown (i.e the TTL controls
 the volume of frequency information leakage per zone).

 So, it would seem to me that DPRIVE should also consider
 the 'B to C' phase. I state this, because TOR already
 provides what only 'A to B' encryption could: anonymity
 based on the volume of users.


 i agree that if an attacker has control over the stub's choice of
 recursive server, such that they can assign the surveillance target a
 particular recursive server, then stub-to-authoritative in the clear
 would be an information leak. however, that overstates the starting
 conditions. the stub's recursive is either manually configured, or it is
 assigned by their DHCP server operator, and either the owner themselves or
 the DHCP server operator have many other methods of collecting this
 traffic. so your starting conditions are operatively equal to the null set.

 ===

 in conclusion, let me strongly urge that DPRIVE consider point solutions
 such as query minimization and an HTTPS based transport between stubs and
 recursives, and