Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op

[Christoph]

Stephane Bortzmeyer wrote:> * "A DNS privacy service must be engineered
for high availability."
> I'm not in favor of this sentence. 1) It seems to despise small 
> resolvers managed by small organisations, while we need many diverse 
> DoT and DoH resolvers, to avoid centralisation 2) Today, Firefox, 
> unfortunately, does not allow to add more than one DoH resolver,
> which makes the DoH resolver a very critical resource. But I hope
> that in the future, we will be able to configure several resolvers,
> with an efficient fallback, making the issue of availability less
> important.

I second that.

> “A DNS privacy service should strive to engineer encrypted services
> to the same availability level as any unencrypted services they
> provide.”?

Sounds good to me.

> * DROP is not a perfect acronym 
+1
maybe "DROPS"?

> "be held only memory"

"in memory.."


kind regards,
Christoph

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

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: AD Evaluation

(The previous state was Publication Requested)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

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

[dns-privacy] Publication has been requested for draft-ietf-dprive-rfc7626-bis-02

[Brian Haberman via Datatracker]

Brian Haberman has requested publication of draft-ietf-dprive-rfc7626-bis-02 as 
Informational on behalf of the DPRIVE working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
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] Second Working Group Last Call for draft-ietf-dprive-bcp-op

[Sara Dickinson]

> From: Stephane Bortzmeyer 
> Subject: Re: [dns-privacy] Second Working Group Last Call for 
> draft-ietf-dprive-bcp-op
> Date: 1 November 2019 at 10:38:31 GMT
> To: Tim Wicinski 
> Cc: dns-privacy@ietf.org
> 
> On Thu, Oct 31, 2019 at 11:24:45AM -0400,
> Tim Wicinski  wrote 
> a message of 113 lines which said:
> 
>> This starts a Second Working Group Last Call for draft-ietf-dprive-bcp-op
> 
> Background: I run a small (very small) public DoH and DoT resolver,
> and it has a DROP (a policy). If you want to read it, it is only in
> french: . I checked it against
> section 6 and appendix C.
> 
> Executive summary: the draft is fine and useful and, IMHO, should be
> published.

Hi Stephane,

Thanks for the review!

> 
> A few issues:
> 
> * the first paragraph of section 4 should be deleted since the draft
> does not use RFC2119 (and rightly so), except one lonely SHOULD in
> section 5.

The current usage is the result of a discussion on the very first version of 
the draft (draft-dickinson-dprive-bcp-op-00, June 2018) and since then 
(limited) usage of RFC2119 language has been present. There have been comments 
on both sides that the language should be stronger and weaker and this was the 
compromise outcome. The SHOULD does ripple through the document though as it 
defines all the Mitigations listed in the later sections as being recommended 
for minimal compliance. How much of an issue is this for you?

> 
> * "A DNS privacy service must be engineered for high availability."
> I'm not in favor of this sentence. 1) It seems to despise small
> resolvers managed by small organisations, while we need many diverse
> DoT and DoH resolvers, to avoid centralisation 2) Today, Firefox,
> unfortunately, does not allow to add more than one DoH resolver, which
> makes the DoH resolver a very critical resource. But I hope that in
> the future, we will be able to configure several resolvers, with an
> efficient fallback, making the issue of availability less important.

I can understand this reading of it but item 1 you list above was not at all 
the goal of this at all text. Perhaps this could be better phrased as 
“A DNS privacy service should strive to engineer encrypted services to the same 
availability level as any unencrypted services they provide.”?

> 
> * DROP is not a perfect acronym since the draft does not talk only
> about privacy but also about integrity ("result filtering", aka lying
> resolvers).

It seems is the best one offered yet - as mentioned previously bike-shedding on 
this is always an option… Vladimir suggested DNS Recursive Operator Policy but 
that seems a little too general to me given the limited scope of the document 
(Privacy services). Do you have a suggestion?

Also, one distinction is that the privacy related policy outlined in a DROP can 
be directly assessed against the privacy mitigations outlined in this document 
to determine a compliance level, whereas the document makes no statements about 
filtering policy requirements. The aim of including them in the DROP is purely 
for transparency.

> 
> * "exporting DNS traffic from the resolver using e.g. dnstap" May be a
> reference to section 6.1.1 about sharing could be a good idea? Today,
> many existing policies say things like "we don't store logs for more
> than N weeks" but are silent on export/sharing…

Or perhaps a reference to Section 5.2 is better as it lists the threats and 
mitigations in detail?

> 
> * "Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the
> number of queries to authoritative servers to increase privacy" RFC
> 8020 could be mentioned, too, for the same goal.

Sure.

> 
> * Appendix B is really good and useful. "The level of anonymization
> this [keeping a /24 for IPv4] produces is perhaps questionable" is
> certainly the understatement of the year :-)

:-)

Best regards

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