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

[Bob Harold]

On Fri, Nov 8, 2019 at 9:17 PM Paul Wouters  wrote:

>
> On Nov 8, 2019, at 20:13, Brian Dickson 
> wrote:
>
>
>
>
> 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.)
>
>
> I have on a few occasions explained to the people running this site that
> they were wrong to blame dnssec. Some listed events were generic outages
> wrongly blamed on dnssec. No corrections were ever made. The side is
> extremely subjectively anti-dnssec.
>
>
>
> 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.
>
>
> Exactly, and why I quoted 8.8.8.8, 1.1.1.1 and 9.9.9.9. So many people are
> behind dnssec validators that validation failure would lead to a quick
> outage notification by tools or humans.
>
> Paul
>


Thanks to everyone for the info and recommendations.  I need to figure out
how to alert on validation failures, and then enable validation.

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

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

[Paul Wouters]

> On Nov 8, 2019, at 20:13, Brian Dickson  wrote:
> 
> 
> 
> 
> 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.)

I have on a few occasions explained to the people running this site that they 
were wrong to blame dnssec. Some listed events were generic outages wrongly 
blamed on dnssec. No corrections were ever made. The side is extremely 
subjectively anti-dnssec. 

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

Exactly, and why I quoted 8.8.8.8, 1.1.1.1 and 9.9.9.9. So many people are 
behind dnssec validators that validation failure would lead to a quick outage 
notification by tools or humans.

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

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

[Paul Ebersman]

stephen> It seems odd that you're telling someone what they ought not be
stephen> worried about. Wouldn't it be better to be convincing that
stephen> there's nothing to worry about?  (E.g. via stats.)

It's a few years out of date but this has actually improved. I was on
the DNS team at comcast. I've confirmed that this is still more or less
what they see.

For 500-600 billion queries per day, 1-2 dozen DNSSEC related failures
per month (modulo a few folks in .mil or .gov that have NTAs for long
standing failures). That's with validation on all queries.

That's in the below noise range. I wish I had packet drop rates in that
range. ;)

___
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

[Stephen Farrell]

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

S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Paul Wouters]

> On Nov 8, 2019, at 17:06, Bob Harold  wrote:
> 
> 
> I hate to admit it, and this is a little off topic, but my resolvers are not 
> (yet) validating.

Then your resolvers’ configuration is years out of date. All resolvers these 
days ship with validation enabled.

> Is there a setting that will attempt to validate, and log if it fails, but 
> still answer the users?

At that point, everyone using 8.8.8.8 or 9.9.9.9 or 1.1.1.1 or any other 
non-opendns resolver would not be able to access that domain. Why would you 
want to override that?

> I hear that there are occasional sites that fail validation, and would like 
> to know what will break if and when I begin to validate.

Nothing that the vast majority of users would already not be able to see.


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

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

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

[Bob Harold]

On Fri, Nov 8, 2019 at 4:37 PM Paul Wouters  wrote:

> On Wed, 6 Nov 2019, 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
>
> Why would a _resolver_ not be validating ?
>
> I understand the reasons for web applications that do not want to do
> validating, though I disagree with those. But for actual DNS resolvers,
> running as DNS caching server on either laptop or in an enterprise, I
> see no valid reason why it should not be validating at this point.
>
> > Any protocol we develop for ADoT capability discovery should prevent
> downgrade attacks but should also work fine for resolvers that do not
> validate.
>
> I strongly disagree. Resolvers towards Authoritative servers are core
> infrastructure, and that core should have no problems using the latest
> DNS RFC's.
>
> Paul
>

I hate to admit it, and this is a little off topic, but my resolvers are
not (yet) validating.
Is there a setting that will attempt to validate, and log if it fails, but
still answer the users?
I hear that there are occasional sites that fail validation, and would like
to know what will break if and when I begin to validate.
I will also need to monitor the added load on the servers, although I don't
expect it to be a problem.
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).

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

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

[Paul Wouters]

On Wed, 6 Nov 2019, 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


Why would a _resolver_ not be validating ?

I understand the reasons for web applications that do not want to do
validating, though I disagree with those. But for actual DNS resolvers,
running as DNS caching server on either laptop or in an enterprise, I
see no valid reason why it should not be validating at this point.


Any protocol we develop for ADoT capability discovery should prevent downgrade 
attacks but should also work fine for resolvers that do not validate.


I strongly disagree. Resolvers towards Authoritative servers are core
infrastructure, and that core should have no problems using the latest
DNS RFC's.

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

[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] [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

[Paul Hoffman]

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.

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

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

[Stephen Farrell]

Hiya,

On 06/11/2019 14:15, Paul Wouters wrote:
> 
>> On Nov 6, 2019, at 04:24, Ralf Weber  wrote:
>>
>>
>>> 4: without expecting everyone to support DNSSEC.
>> Really. I can not see how we design something new that does not take DNSSEC 
>> into account.
> 
> Indeed. The longer we treat DNSSEC as optional, the longer we will be faced 
> with adoption problems, exactly as with IPv6.
> 
> We talk a lot about the DNS camel, but the “avoid DNSSEC” camel has quite the 
> number of pages in RFCs now.

Interesting. I read Warren's text as being "don't require
DNSSEC having been deployed" while you and Ralf seem to be
reading the same text as "don't take DNSSEC into account"
or "avoid DNSSEC."

I'm fine with Warren's text FWIW. ISTM that ~1% deployment
after this elapsed time means that depending on DNSSEC
deployment is just... unwise. ("Unwise" wasn't the first
word I typed there btw;-) Being to be able to benefit
from DNSSEC deployment is a good thing, but a different
thing. I also think trying to avoid or ignore DNSSEC is
almost but not quite as unwise as requiring DNSSEC
deployment.

Maybe these different interpretations of the same text
are indicators that many of us are reading too much
between too many lines?

Cheers,
S.



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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Paul Wouters]

> On Nov 6, 2019, at 04:24, Ralf Weber  wrote:
> 
> 
>> 4: without expecting everyone to support DNSSEC.
> Really. I can not see how we design something new that does not take DNSSEC 
> into account.

Indeed. The longer we treat DNSSEC as optional, the longer we will be faced 
with adoption problems, exactly as with IPv6.

We talk a lot about the DNS camel, but the “avoid DNSSEC” camel has quite the 
number of pages in RFCs now.

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

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

[Hugo Connery]

On Tue, 2019-11-05 at 09:47 -0500, Paul Wouters wrote:
> On Tue, 5 Nov 2019, Warren Kumari wrote:
> 
> > $ dig ns a.example.com
> > ;; ANSWER SECTION:
> > a.example.com. 42923 IN NS ns1-dot.nameservers.example.
> > a.example.com. 42923 IN NS ns2.nameservers.example.
> > 
> > Now, if you cannot reach ns1-dot.nameservers.example, whether you
> > fall
> > back to ns2.nameservers.example is a matter of client policy /
> > paranoia. As this is an *opportunistic* / better than nothing
> > solution
> > I'd think that falling back makes sense. This really really isn't a
> > replacement for a more secure, downgrade resistant solution (like
> > Paul's), but it *is* an incrementally deployable, opportunistic
> > convention based solution. We could do it while figuring out a
> > better,
> > more secure system...
> 
> I guess you need to use ns1-dot and not a TLSA record for
> _853._tcp.ns1-dot.nameservers.example.  because no sane
> implementation
> of anything would trust unsigned TLSA records. That also says
> something. Opportunistic does not have to mean soft fail.
> 
> If you are going to accept a downgrade when under attack, why even
> bother with any signaling using name hacks and just try port 853 on
> all nameservers, and remember the ones that failed and succeeded for
> a
> little while? Then you truly do not need any coordination between
> your
> nameserver operators at all, for those who depend on secondaries that
> they do not control the software of.
> 
> Paul

If the initial goal, as suggested by Stephen, is to deploy an 
opportunitistic DoT to encourage deployment, then Paul's suggestion
above which de-couples the recursive and authoritative seems wise.

This gets "the ball further down the road" while deciding about a
more rigorous solution in which recursive resolvers attempt to honour
client policy (do fallback, dont fallback, etc.) and how authoritatives
advertise their DoT service is developed.

Regards,
-- 
Hugo Connery, Head of IT, Dept. Environmental Engineering
Technical University of Denmark, http://www.env.dtu.dk

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

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

[Ralf Weber]

Moin!

On 6 Nov 2019, at 0:13, Warren Kumari wrote:

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)
Why does the parent to be upgraded to DoT? It can just indicate a DoT 
server for a child. These are normal DNS semantics.



2:  without having people to probe and wait for a timeout
Again resolution follows the delegation, so that is the best place to 
put this in.



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.
Well as long as you are ok with that someone wants to something in 
kumari.net that should work. However maybe it is good to remind people 
that public DNS data is public so keeping something secret is hard to 
impossible. Also there has been some research presented at the ANRW 
workshop that even when hiding all DNS traffic from an observer it still 
is possible to digest what user visited by only looking at the IP 
addresses. ( https://irtf.org/anrw/2019/program.html - What Can You 
Learn from an IP). As said before if we really want privacy for users we 
have to fully encrypt and obfuscate layer 3.



4: without expecting everyone to support DNSSEC.
Really. I can not see how we design something new that does not take 
DNSSEC into account. That would negate a lot of hard work done by a lot 
of people over decades. Would you design something new without taking 
IPv6 into account?


So long
-Ralf
—--
Ralf Weber

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

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

[Mark Andrews]

You can always send a QUERY with no question.  It’s not perfect, as it is 
subject
to downgrade attacks, but does allow you to probe server capabilities.

% dig +ednsopt=100 +header-only +qr

; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>> +ednsopt +header-only +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38660
;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab59773fd258541b
; OPT=100
;; QUESTION SECTION:

;; QUERY SIZE: 39

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38660
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab59773fd258541b01005dc24d3939228b15d289bab4 (good)
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 06 15:34:01 AEDT 2019
;; MSG SIZE  rcvd: 51

% 


> On 6 Nov 2019, at 10:13, 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)
> 
> W
> 
> 
> 
>> 
>> Paul
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

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

[Dan Wing]

On Nov 5, 2019, at 3:13 PM, Warren Kumari  wrote:


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

Perhaps encode feature flags into the last digits of the SOA's Expire time?  
For example kumari.net  has an expire time of 1209600, and 
those last two (decimal) digits could be used for binary encoding feature 
flags, so 1209601 = DoT, 1209602 = DoH, 1209603 = DoT and DoH, and so on.  This 
gives us 6 feature flags we could shove into Expire time.

-d

___
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

[Warren Kumari]

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)

W



>
> Paul



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

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

[Warren Kumari]

On Tue, Nov 5, 2019 at 9:47 AM Paul Wouters  wrote:

> On Tue, 5 Nov 2019, Warren Kumari wrote:
>
> > $ dig ns a.example.com
> > ;; ANSWER SECTION:
> > a.example.com. 42923 IN NS ns1-dot.nameservers.example.
> > a.example.com. 42923 IN NS ns2.nameservers.example.
> >
> > Now, if you cannot reach ns1-dot.nameservers.example, whether you fall
> > back to ns2.nameservers.example is a matter of client policy /
> > paranoia. As this is an *opportunistic* / better than nothing solution
> > I'd think that falling back makes sense. This really really isn't a
> > replacement for a more secure, downgrade resistant solution (like
> > Paul's), but it *is* an incrementally deployable, opportunistic
> > convention based solution. We could do it while figuring out a better,
> > more secure system...
>
> I guess you need to use ns1-dot and not a TLSA record for
> _853._tcp.ns1-dot.nameservers.example.  because no sane implementation
> of anything would trust unsigned TLSA records. That also says
> something. Opportunistic does not have to mean soft fail.
>
> If you are going to accept a downgrade when under attack, why even
> bother with any signaling using name hacks and just try port 853 on
> all nameservers, and remember the ones that failed and succeeded for a
> little while? Then you truly do not need any coordination between your
> nameserver operators at all, for those who depend on secondaries that
> they do not control the software of.


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

W



>
> Paul
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Warren Kumari]

On Mon, Nov 4, 2019 at 5:13 PM Eric Rescorla  wrote:
>
>
>
> 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 ?
>>
>> 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.
>
>
> This is a good point, and seems like an argument against all of the 
> opportunistic versions as well, even those with HSTS-style mechanisms.
>
> Suppose I look up a.example.com and get ns1.nameservers.example and 
> ns2.nameservers.example, and I have talked to ns1 and know it does Dot but I 
> don't know about ns2. What then? Or say I can't connect to ns1


$ dig ns a.example.com
;; ANSWER SECTION:
a.example.com. 42923 IN NS ns1-dot.nameservers.example.
a.example.com. 42923 IN NS ns2.nameservers.example.

Now, if you cannot reach ns1-dot.nameservers.example, whether you fall
back to ns2.nameservers.example is a matter of client policy /
paranoia. As this is an *opportunistic* / better than nothing solution
I'd think that falling back makes sense. This really really isn't a
replacement for a more secure, downgrade resistant solution (like
Paul's), but it *is* an incrementally deployable, opportunistic
convention based solution. We could do it while figuring out a better,
more secure system...

W
>
> -Ekr
>
>> Paul
>>
>> ___
>> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

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

[Paul Wouters]

On Tue, 5 Nov 2019, Warren Kumari wrote:


$ dig ns a.example.com
;; ANSWER SECTION:
a.example.com. 42923 IN NS ns1-dot.nameservers.example.
a.example.com. 42923 IN NS ns2.nameservers.example.

Now, if you cannot reach ns1-dot.nameservers.example, whether you fall
back to ns2.nameservers.example is a matter of client policy /
paranoia. As this is an *opportunistic* / better than nothing solution
I'd think that falling back makes sense. This really really isn't a
replacement for a more secure, downgrade resistant solution (like
Paul's), but it *is* an incrementally deployable, opportunistic
convention based solution. We could do it while figuring out a better,
more secure system...


I guess you need to use ns1-dot and not a TLSA record for
_853._tcp.ns1-dot.nameservers.example.  because no sane implementation
of anything would trust unsigned TLSA records. That also says
something. Opportunistic does not have to mean soft fail.

If you are going to accept a downgrade when under attack, why even
bother with any signaling using name hacks and just try port 853 on
all nameservers, and remember the ones that failed and succeeded for a
little while? Then you truly do not need any coordination between your
nameserver operators at all, for those who depend on secondaries that
they do not control the software of.

Paul

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

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

[Tony Finch]

John Levine  wrote:
> In article  you write:
> >> That's per-zone, though, whereas DoT support is per-server.
> >
> >Maybe that's ideal, but one would expect that a zone only rolls this
> >out once all their nameservers support it.
>
> Most of my zones have a secondary run by somebody else, whose software
> is never in sync with mine.

Yes, also it's operationally much less stressful if you can use a canary
deployment to verify a partial roll-out before full deployment.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Cyclonic 4 to 6, increasing 7 in far northwest. Moderate or
rough. Wintry showers. Good, occasionally poor.

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

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

[John Levine]

In article  you write:
>> That's per-zone, though, whereas DoT support is per-server.
>
>Maybe that's ideal, but one would expect that a zone only rolls this
>out once all their nameservers support it.

Most of my zones have a secondary run by somebody else, whose software
is never in sync with mine.  It's also fairly common for large operators
to mitigate their DNS risk by spreading DNS across multiple providers.
If you have to wait until every server can do ADoT rather than until
some of them can, that will make deployment a lot slower.

> Otherwise, whether or not
>resolvers do DoT to authoritative servers would be an odd game of
>russian roulette depending on which NS record was followed, something
>that could even be tweaked by an attacker, like by stripping glue from
>the ones that did support it.

There are plenty of signal schemes that don't fail that way.  See my
recent draft.

>> DS records that somehow encode NS target names in their rdata might
>> work...
>
>That still leaves too much control at the parent to change it against
>the child's wishes. A DNSKEY flag commits the child zone using publication
>at its parent without giving the parent a veto.

The parent zone always has a veto.  It can remove the NS or DS records if it
doesn't like what the child is doing.

R's,
John

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

[Eric Rescorla]

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

This is a good point, and seems like an argument against all of the
opportunistic versions as well, even those with HSTS-style mechanisms.

Suppose I look up a.example.com and get ns1.nameservers.example and
ns2.nameservers.example, and I have talked to ns1 and know it does Dot but
I don't know about ns2. What then? Or say I can't connect to ns1

-Ekr

Paul
>
> ___
> 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 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] [Ext] Threat Model

[Paul Wouters]

On Mon, 4 Nov 2019, Tony Finch wrote:


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

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.


Maybe that's ideal, but one would expect that a zone only rolls this
out once all their nameservers support it. Otherwise, whether or not
resolvers do DoT to authoritative servers would be an odd game of
russian roulette depending on which NS record was followed, something
that could even be tweaked by an attacker, like by stripping glue from
the ones that did support it.


DS records that somehow encode NS target names in their rdata might
work...


That still leaves too much control at the parent to change it against
the child's wishes. A DNSKEY flag commits the child zone using publication
at its parent without giving the parent a veto.

Paul

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

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

[Tony Finch]

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.

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

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

[Stephen Farrell]

Hi Eric,

I mostly agree with your analysis (other than maybe we'd
be better off to more precisely distinguish https vs. tls,
as we figure this out.

Just one clarification:

On 02/11/2019 19:58, Eric Rescorla wrote:
> 
> 
>> ISTM that requiring day-1 defence against active attacks was to an
>> extent responsible for the lack of deployment
>> of IPsec and DNSSEC,
> 
> I don't understand what DNSSEC would do if not defend against active
> attack.

What I meant was that the dependency on the parent for
DNSSEC was driven by that requirement for preventing
active attacks on day-1, but the dependency on the parent
making changes has also been a serious obstacle to
deployment.

In contrast, things like dkim, dmarc and mta-sts come
with testing modes and reporting, which I think helps
deployment.

What I'm asking is that we consider those kinds of
make-deployment-easier features as well when figuring
out adot (regardless of whether or not we end up with
an opportunistic approach).

Cheers,
S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Paul Wouters]

> On Nov 3, 2019, at 07:27, Warren Kumari  wrote:
> 
>> Can you expand on this? Is the convention that if I see x-dot.example.com, 
>> then I should expect DoT?
> 
> Yup, that’s it exactly.
> 
> As a DNS person, encoding semantics into the name makes me twitch

It should do more than cause a twitch.

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.

Telling people to make security decisions based on unsigned DNS glue is not a 
good idea.

If you use DNS to signal security information, you have to accept requiring 
DNSSEC.

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

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

[David Conrad]

Warren,

On Nov 3, 2019, at 7:27 AM, Warren Kumari  wrote:
> Can you expand on this? Is the convention that if I see x-dot.example.com 
> , then I should expect DoT?
> 
> Yup, that’s it exactly.
> 
> As a DNS person, encoding semantics into the name makes me twitch, and I’m 
> concerned we eventually end up with:
> x-dot-doh-ipv4-and-IPv6-I-also-support-tcp-far-our-in-the-uncharted-backwaters-of-the-western-spiral-arm.example.com
>  
> ,
>  but as a pragmatic and deployment it seem to work.
> 
> A suitably positioned *active* attacker could probably still cause a 
> downgrade (because glue isn’t signed), but it requires much more work on the 
> attackers part than:
> deny I do any any 853
> permit ip any any
> 
> This also gives us the opportunity for a bikeshed discussion re: what label 
> to use :-)

Oh! Bikeshedding! Yay! You could do x-.example.com!

What’s the emoji for tongue-in-cheek again?

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Warren Kumari]

On Sat, Nov 2, 2019 at 10:01 PM Eric Rescorla  wrote:

>
>
> On Sat, Nov 2, 2019 at 6:02 PM Warren Kumari  wrote:
>
>> On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla  wrote:
>> >
>> >
>> >
>> > On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <
>> stephen.farr...@cs.tcd.ie> wrote:
>> >>
>> >>
>> >> Hiya,
>> >>
>> >> On 02/11/2019 18:33, Eric Rescorla wrote:
>> >> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman 
>> wrote:
>> >> >
>> >> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
>> >> >>> Generally, I would expect that a solution which addressed the
>> active
>> >> >> threat model would also address the passive one.
>> >> >>
>> >> >> Of course, but there are many threat models that have different
>> solutions.
>> >> >> The passive threat models might be addressable more quickly than
>> the active
>> >> >> threat model.
>> >> >>
>> >> >
>> >> > Yes, that's why I asked the question of whether we are trying to
>> solve the
>> >> > active attacker case.
>> >>
>> >> Tackling passive and active attacks are not mutually
>> >> exclusive goals.
>> >
>> >
>> > Nor did I say they were.
>> >
>> >
>> >>
>> >> Experience from SMTP/TLS (as I interpret it anyway)
>> >> was that defence against active attacks only really
>> >> became tractable a few years after mitigations against
>> >> passive attacks had been deployed and clearly hadn't
>> >> broken anything. Note that that transition did not require any changes
>> >> to SMTP/TLS, though it may have needed
>> >> the mail equivalent of HSTS and reporting to have been
>> >> defined (it's hard to tell what really motivated folks
>> >> to try mitigate active attacks for sure).
>> >>
>> >> Whether or not adot is sufficiently similar is (for me)
>> >> an unknown at this point but I'd hope we don't rule that
>> >> out.
>> >
>> >
>> > I think the primary difference between this case and the TLS case,
>> > where, as I note below, defense against active attacks was required from
>> > the beginning, is the question of whether or not the reference that
>> > the initiator has tells it that it supposed to expect security. In the
>> case
>> > of TLS you have that with the different URI scheme (https) but in
>> > the case of email you do not.
>> >
>> > Conversely, what made opportunistic style approaches viable for
>> > SMTP was that there was an existing protocol handshake that
>> > could be conveniently adopted to have upward negotiation (STARTTLS).
>> > This was more of a pain with HTTP, though RFC 2817 does in fact
>> > specify something.
>> >
>> > In this case, I think the relevant question is whether there is some
>> > viable mechanism (by which I mean one that people might actually
>> > use) by which recursive resolvers would, in talking to an authoritative
>> > resolver, detect that that resolver supported secure transport and
>> > upgrade. If there is, then it's potentially possible to have some kind
>> > of opportunistic approach. And conversely, whether it's viable
>> > to have the records that point you to the next authoritative convey
>> > that you should expect security.. If there is, then it's potentially
>> > possible/better to have a non-opportunistic approach
>>
>> I've suggested a number of times, but haven't actually written up,
>> that you could encode this in the nameserver name - this is somewhat
>> similar to the dnscrypt idea...
>>
>> E.g - no DoX expected:
>> $ dig ns example.com
>> ;; ANSWER SECTION:
>> example.com. 42923 IN NS b.iana-servers.net.
>> example.com. 42923 IN NS a.iana-servers.net.
>>
>> Recursive resolvers should expect DoT:
>> $ dig ns example.com
>> ;; ANSWER SECTION:
>> example.com. 42923 IN NS b-dot.iana-servers.net.
>> example.com. 42923 IN NS a-dot.iana-servers.net.
>>
>>
>> Yes, I'll be the first to admit that it is hacky, and not it's not
>> completely foolproof, but it requires an attacker to do more than just
>> block port 853 to force a downgrade, and also means that resolvers
>> don't have to probe 853, wait for a timeout and then try 53
>> instead
>>
>
> Can you expand on this? Is the convention that if I see x-dot.example.com,
> then I should expect DoT?
>

Yup, that’s it exactly.

As a DNS person, encoding semantics into the name makes me twitch, and I’m
concerned we eventually end up with:
x-dot-doh-ipv4-and-IPv6-I-also-support-tcp-far-our-in-the-uncharted-backwaters-of-the-western-spiral-arm.example.com,
but as a pragmatic and deployment it seem to work.

A suitably positioned *active* attacker could probably still cause a
downgrade (because glue isn’t signed), but it requires much more work on
the attackers part than:
deny I do any any 853
permit ip any any

This also gives us the opportunity for a bikeshed discussion re: what label
to use :-)

w


>
> -Ekr
>
>
>> W
>>
>>
>>
>> >
>> >
>> >>
>> >> ISTM that requiring day-1 defence against active attacks was to an
>> >> extent responsible for the lack of deployment
>> >> of IPsec and DNSSEC,
>> >
>> >
>> > I don't understand what DNSSEC would do if not defend against active
>> > 

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 6:02 PM Warren Kumari  wrote:

> On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla  wrote:
> >
> >
> >
> > On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
> >>
> >>
> >> Hiya,
> >>
> >> On 02/11/2019 18:33, Eric Rescorla wrote:
> >> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman 
> wrote:
> >> >
> >> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> >> >>> Generally, I would expect that a solution which addressed the active
> >> >> threat model would also address the passive one.
> >> >>
> >> >> Of course, but there are many threat models that have different
> solutions.
> >> >> The passive threat models might be addressable more quickly than the
> active
> >> >> threat model.
> >> >>
> >> >
> >> > Yes, that's why I asked the question of whether we are trying to
> solve the
> >> > active attacker case.
> >>
> >> Tackling passive and active attacks are not mutually
> >> exclusive goals.
> >
> >
> > Nor did I say they were.
> >
> >
> >>
> >> Experience from SMTP/TLS (as I interpret it anyway)
> >> was that defence against active attacks only really
> >> became tractable a few years after mitigations against
> >> passive attacks had been deployed and clearly hadn't
> >> broken anything. Note that that transition did not require any changes
> >> to SMTP/TLS, though it may have needed
> >> the mail equivalent of HSTS and reporting to have been
> >> defined (it's hard to tell what really motivated folks
> >> to try mitigate active attacks for sure).
> >>
> >> Whether or not adot is sufficiently similar is (for me)
> >> an unknown at this point but I'd hope we don't rule that
> >> out.
> >
> >
> > I think the primary difference between this case and the TLS case,
> > where, as I note below, defense against active attacks was required from
> > the beginning, is the question of whether or not the reference that
> > the initiator has tells it that it supposed to expect security. In the
> case
> > of TLS you have that with the different URI scheme (https) but in
> > the case of email you do not.
> >
> > Conversely, what made opportunistic style approaches viable for
> > SMTP was that there was an existing protocol handshake that
> > could be conveniently adopted to have upward negotiation (STARTTLS).
> > This was more of a pain with HTTP, though RFC 2817 does in fact
> > specify something.
> >
> > In this case, I think the relevant question is whether there is some
> > viable mechanism (by which I mean one that people might actually
> > use) by which recursive resolvers would, in talking to an authoritative
> > resolver, detect that that resolver supported secure transport and
> > upgrade. If there is, then it's potentially possible to have some kind
> > of opportunistic approach. And conversely, whether it's viable
> > to have the records that point you to the next authoritative convey
> > that you should expect security.. If there is, then it's potentially
> > possible/better to have a non-opportunistic approach
>
> I've suggested a number of times, but haven't actually written up,
> that you could encode this in the nameserver name - this is somewhat
> similar to the dnscrypt idea...
>
> E.g - no DoX expected:
> $ dig ns example.com
> ;; ANSWER SECTION:
> example.com. 42923 IN NS b.iana-servers.net.
> example.com. 42923 IN NS a.iana-servers.net.
>
> Recursive resolvers should expect DoT:
> $ dig ns example.com
> ;; ANSWER SECTION:
> example.com. 42923 IN NS b-dot.iana-servers.net.
> example.com. 42923 IN NS a-dot.iana-servers.net.
>
>
> Yes, I'll be the first to admit that it is hacky, and not it's not
> completely foolproof, but it requires an attacker to do more than just
> block port 853 to force a downgrade, and also means that resolvers
> don't have to probe 853, wait for a timeout and then try 53
> instead
>

Can you expand on this? Is the convention that if I see x-dot.example.com,
then I should expect DoT?

-Ekr


> W
>
>
>
> >
> >
> >>
> >> ISTM that requiring day-1 defence against active attacks was to an
> >> extent responsible for the lack of deployment
> >> of IPsec and DNSSEC,
> >
> >
> > I don't understand what DNSSEC would do if not defend against active
> > attack.
> >
> >
> >> so I hope we keep an eye on that
> >> ball too.
> >
> >
> > OTOH, TLS had day one defense against active attacks.
> >
> > -Ekr
> >
> > ___
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Warren Kumari]

On Sat, Nov 2, 2019 at 3:59 PM Eric Rescorla  wrote:
>
>
>
> On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell  
> wrote:
>>
>>
>> Hiya,
>>
>> On 02/11/2019 18:33, Eric Rescorla wrote:
>> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman  wrote:
>> >
>> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
>> >>> Generally, I would expect that a solution which addressed the active
>> >> threat model would also address the passive one.
>> >>
>> >> Of course, but there are many threat models that have different solutions.
>> >> The passive threat models might be addressable more quickly than the 
>> >> active
>> >> threat model.
>> >>
>> >
>> > Yes, that's why I asked the question of whether we are trying to solve the
>> > active attacker case.
>>
>> Tackling passive and active attacks are not mutually
>> exclusive goals.
>
>
> Nor did I say they were.
>
>
>>
>> Experience from SMTP/TLS (as I interpret it anyway)
>> was that defence against active attacks only really
>> became tractable a few years after mitigations against
>> passive attacks had been deployed and clearly hadn't
>> broken anything. Note that that transition did not require any changes
>> to SMTP/TLS, though it may have needed
>> the mail equivalent of HSTS and reporting to have been
>> defined (it's hard to tell what really motivated folks
>> to try mitigate active attacks for sure).
>>
>> Whether or not adot is sufficiently similar is (for me)
>> an unknown at this point but I'd hope we don't rule that
>> out.
>
>
> I think the primary difference between this case and the TLS case,
> where, as I note below, defense against active attacks was required from
> the beginning, is the question of whether or not the reference that
> the initiator has tells it that it supposed to expect security. In the case
> of TLS you have that with the different URI scheme (https) but in
> the case of email you do not.
>
> Conversely, what made opportunistic style approaches viable for
> SMTP was that there was an existing protocol handshake that
> could be conveniently adopted to have upward negotiation (STARTTLS).
> This was more of a pain with HTTP, though RFC 2817 does in fact
> specify something.
>
> In this case, I think the relevant question is whether there is some
> viable mechanism (by which I mean one that people might actually
> use) by which recursive resolvers would, in talking to an authoritative
> resolver, detect that that resolver supported secure transport and
> upgrade. If there is, then it's potentially possible to have some kind
> of opportunistic approach. And conversely, whether it's viable
> to have the records that point you to the next authoritative convey
> that you should expect security.. If there is, then it's potentially
> possible/better to have a non-opportunistic approach

I've suggested a number of times, but haven't actually written up,
that you could encode this in the nameserver name - this is somewhat
similar to the dnscrypt idea...

E.g - no DoX expected:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 42923 IN NS b.iana-servers.net.
example.com. 42923 IN NS a.iana-servers.net.

Recursive resolvers should expect DoT:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 42923 IN NS b-dot.iana-servers.net.
example.com. 42923 IN NS a-dot.iana-servers.net.


Yes, I'll be the first to admit that it is hacky, and not it's not
completely foolproof, but it requires an attacker to do more than just
block port 853 to force a downgrade, and also means that resolvers
don't have to probe 853, wait for a timeout and then try 53
instead

W



>
>
>>
>> ISTM that requiring day-1 defence against active attacks was to an
>> extent responsible for the lack of deployment
>> of IPsec and DNSSEC,
>
>
> I don't understand what DNSSEC would do if not defend against active
> attack.
>
>
>> so I hope we keep an eye on that
>> ball too.
>
>
> OTOH, TLS had day one defense against active attacks.
>
> -Ekr
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 11:52 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 02/11/2019 18:33, Eric Rescorla wrote:
> > On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman 
> wrote:
> >
> >> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> >>> Generally, I would expect that a solution which addressed the active
> >> threat model would also address the passive one.
> >>
> >> Of course, but there are many threat models that have different
> solutions.
> >> The passive threat models might be addressable more quickly than the
> active
> >> threat model.
> >>
> >
> > Yes, that's why I asked the question of whether we are trying to solve
> the
> > active attacker case.
>
> Tackling passive and active attacks are not mutually
> exclusive goals.
>

Nor did I say they were.



> Experience from SMTP/TLS (as I interpret it anyway)
> was that defence against active attacks only really
> became tractable a few years after mitigations against
> passive attacks had been deployed and clearly hadn't
> broken anything. Note that that transition did not require any changes
> to SMTP/TLS, though it may have needed
> the mail equivalent of HSTS and reporting to have been
> defined (it's hard to tell what really motivated folks
> to try mitigate active attacks for sure).
>
> Whether or not adot is sufficiently similar is (for me)
> an unknown at this point but I'd hope we don't rule that
> out.
>

I think the primary difference between this case and the TLS case,
where, as I note below, defense against active attacks was required from
the beginning, is the question of whether or not the reference that
the initiator has tells it that it supposed to expect security. In the case
of TLS you have that with the different URI scheme (https) but in
the case of email you do not.

Conversely, what made opportunistic style approaches viable for
SMTP was that there was an existing protocol handshake that
could be conveniently adopted to have upward negotiation (STARTTLS).
This was more of a pain with HTTP, though RFC 2817 does in fact
specify something.

In this case, I think the relevant question is whether there is some
viable mechanism (by which I mean one that people might actually
use) by which recursive resolvers would, in talking to an authoritative
resolver, detect that that resolver supported secure transport and
upgrade. If there is, then it's potentially possible to have some kind
of opportunistic approach. And conversely, whether it's viable
to have the records that point you to the next authoritative convey
that you should expect security. If there is, then it's potentially
possible/better to have a non-opportunistic approach



> ISTM that requiring day-1 defence against active attacks was to an
> extent responsible for the lack of deployment
> of IPsec and DNSSEC,


I don't understand what DNSSEC would do if not defend against active
attack.


so I hope we keep an eye on that
> ball too.
>

OTOH, TLS had day one defense against active attacks.

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

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

[Stephen Farrell]

Hiya,

On 02/11/2019 18:33, Eric Rescorla wrote:
> On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman  wrote:
> 
>> On 11/2/19 9:58 AM, Eric Rescorla wrote:
>>> Generally, I would expect that a solution which addressed the active
>> threat model would also address the passive one.
>>
>> Of course, but there are many threat models that have different solutions.
>> The passive threat models might be addressable more quickly than the active
>> threat model.
>>
> 
> Yes, that's why I asked the question of whether we are trying to solve the
> active attacker case.

Tackling passive and active attacks are not mutually
exclusive goals.

Experience from SMTP/TLS (as I interpret it anyway)
was that defence against active attacks only really
became tractable a few years after mitigations against
passive attacks had been deployed and clearly hadn't
broken anything. Note that that transition did not require any changes
to SMTP/TLS, though it may have needed
the mail equivalent of HSTS and reporting to have been
defined (it's hard to tell what really motivated folks
to try mitigate active attacks for sure).

Whether or not adot is sufficiently similar is (for me)
an unknown at this point but I'd hope we don't rule that
out.

ISTM that requiring day-1 defence against active attacks was to an
extent responsible for the lack of deployment
of IPsec and DNSSEC, so I hope we keep an eye on that
ball too.

Cheers,
S.

PS: In saying the above, I do ack that a bunch of people
that I respect a lot totally disagree with the whole
idea of opportunistic security (cf. RFC7435). What I
suggest is that we not regurgitate that debate, but just
bear in mind that any of us can be wrong, especially
when we're arguing about foundational stuff that may
really be based on hunches:-)


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


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 7:03 AM Paul Hoffman  wrote:

> On 11/2/19 9:58 AM, Eric Rescorla wrote:
> > Generally, I would expect that a solution which addressed the active
> threat model would also address the passive one.
>
> Of course, but there are many threat models that have different solutions.
> The passive threat models might be addressable more quickly than the active
> threat model.
>

Yes, that's why I asked the question of whether we are trying to solve the
active attacker case.

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

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

[Paul Hoffman]

On 11/2/19 9:58 AM, Eric Rescorla wrote:
> Generally, I would expect that a solution which addressed the active threat 
> model would also address the passive one.

Of course, but there are many threat models that have different solutions. The 
passive threat models might be addressable more quickly than the active threat 
model.

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

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

[Eric Rescorla]

On Sat, Nov 2, 2019 at 6:01 AM Paul Hoffman  wrote:

> On 11/1/19 2:09 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].
> >
> >
> > 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.
> >
> > Do people agree with this assessment of the situation? Is this form
> > of attack something they agree should be in scope?
>
> This is one threat model, definitely. Another is passive snooping, such by
> someone who is watching at a point on the resolver's upstream connection to
> interesting authoritative servers. Another is passive snooping, such by
> someone who is watching at a point near interesting authoritative servers.
>

Generally, I would expect that a solution which addressed the active threat
model would also address the passive one.



> One small modification I would make to your mode is to change #1 from
> "knowing the expected name of the authoritative" to "knowing an expected
> identifier of the authoritative", and #2 to "...actually has that
> identifier". Given the current landscape of resolvers and authoritative
> servers, using long-lived IP addresses for identification might be better;
> that would need to be hashed out during protocol discussion.
>

Sure. Let's say "identity"

=Ekr


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

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

[Paul Hoffman]

On 11/1/19 2:09 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].
> 
> 
> 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.
> 
> Do people agree with this assessment of the situation? Is this form
> of attack something they agree should be in scope?

This is one threat model, definitely. Another is passive snooping, such by 
someone who is watching at a point on the resolver's upstream connection to 
interesting authoritative servers. Another is passive snooping, such by someone 
who is watching at a point near interesting authoritative servers.

One small modification I would make to your mode is to change #1 from "knowing 
the expected name of the authoritative" to "knowing an expected identifier of 
the authoritative", and #2 to "...actually has that identifier". Given the 
current landscape of resolvers and authoritative servers, using long-lived IP 
addresses for identification might be better; that would need to be hashed out 
during protocol discussion.

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