Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

[Stephane Bortzmeyer]

On Tue, Mar 28, 2023 at 09:29:46PM +0900,
 Ralf Weber  wrote 
 a message of 30 lines which said:

> As I don’t think probing for secure transport is a good idea and
> hope that we will come up with better solutions that follows the DNS
> delegation model.

You mean the parent announcing the zone has ADoT servers? This seems a
good way to have discrepancies between the announce and the reality.

> While I think using IP addresses for authoritative server selection
> is a natural choice there have been cases where an authoritative
> server on the same IP answers differently deepening on the domain
> asked, which will not work well with the detailed implementation of
> that draft.

The point is that this draft is an opportunity to state clearly what
we expect from the authoritative name servers. Requesting that all
instances at the same IP address have DoT does not seem unreasonable
but, indeed, it is not written anywhere yet.

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

[dns-privacy] IETF 116 hackathon on ADoT unilateral probing

[Stephane Bortzmeyer]

[Already sent on the list but, apparently, some people missed it and
asked for it to be in its own thread.]

Following the work done at the DNS table, during the hackathon:

* PowerDNS Recursor implements unilateral probing (but not *this*
unilateral probing, it differs from the draft, see the questions
later) and it works for existing zones, whether they have all their
authoritative name servers DoT-enabled, only some, or not at all. No
problem was observed.

* Unbound implementation is not ready, but I let Yorgos elaborate on
this point.

Some questions were raised about the draft, giving the experience with
PowerDNS Recursor:

* If the ADoT server replies but the reply indicates an error,
  such as SERVFAIL or REFUSED, should the resolver retries without
  DoT? PowerDNS recursor does it, but it seems it would make more
  sense to accept the reply, and just to remind system
  administrators that port 853 and 53 should deliver consistent
  answers. The draft seems clear on the first point (as long as
  there is a properly formatted DNS request, regard the server as
  DoT-enabled) but not on the second (no clear reminder for
  authoritative name servers).

* What should be the criteria to select an authoritative name
  server to query? Should we prefer a fast insecure server or a slow
  encrypted one? The draft does not mention it, because it is local
  policy. (PowerDNS recursor has apparently no way to change its
  default policy, which is to use the fastest one, DoT or
  not.) The draft does not mandate such a knob in the authoritative
  server, again, IETF typically does not tell endpoints how they have
  to be configured.
  
* Should we do lazy probing, like PowerDNS Recursor does, or
  use the more eager "happy eyeballs" algorithm of the current draft?
  
Also, currently, regarding the possible warning to system
administrators about the need for 53 and 853 to be in sync, we
currently find in the wild servers that implement different services on
the two ports. See for instance ns1.eu.org (authoritative for eu.org)
or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both
have authoritative on 53 and an open resolver on 853. Should we
explicitely ban this practice?

You may find some details of this work during the hackathon on my article:

https://www.bortzmeyer.org/hackathon-ietf-116.html



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

Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing

[Stephane Bortzmeyer]

On Mon, Mar 27, 2023 at 11:03:17AM +,
 Paul Hoffman  wrote 
 a message of 8 lines which said:

> Thanks for the implementation work at the Hackathon, and thanks to
> Libor and Florian for the comments. Given that we are in WG Last
> Call, we (the co-authors) will deal with them in the coming
> weeks. We'd love to hear more about implementations and additional
> issues;

I don't know if you saw it, but ADoT probing in PowerDNS recursor, and
their choices, were documented in:

https://blog.powerdns.com/2022/06/13/probing-dot-support-of-authoritative-servers-just-try-it/

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

Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

[Stephane Bortzmeyer]

On Mon, Mar 20, 2023 at 10:35:07AM +0100,
 Joey Salazar  wrote 
 a message of 115 lines which said:

> On this note, we the authors want to invite folks to participate in
> this week's Hackathon: I'll be there on Sunday and Benno and Yorgos
> from NLnet Labs will be there since Saturday working on unilateral
> probing in Unbound.

Following the work done at the DNS table, during the hackathon:

* PowerDNS Recursor implements unilateral probing (but not *this*
unilateral probing, it differs from the draft, see the questions
later) and it works for existing zones, whether they have all their
authoritative name servers DoT-enabled, only some, or not at all. No
problem was observed.

* Unbound implementation is not ready, but I let Yorgos elaborate on
this point.

Some questions were raised about the draft, giving the experience with
PowerDNS Recursor:

* If the ADoT server replies but the reply indicates an error,
  such as SERVFAIL or REFUSED, should the resolver retries without
  DoT? PowerDNS recursor does it, but it seems it would make more
  sense to accept the reply, and just to remind system
  administrators that port 853 and 53 should deliver consistent
  answers. The draft seems clear on the first point (as long as
  there is a properly formatted DNS request, regard the server as
  DoT-enabled) but not on the second (no clear reminder for
  authoritative name servers).

* What should be the criteria to select an authoritative name
  server to query? Should we prefer a fast insecure server or a slow
  encrypted one? The draft does not mention it, because it is local
  policy. (PowerDNS recursor has apparently no way to change its
  default policy, which is to use the fastest one, DoT or
  not.) The draft does not mandate such a knob in the authoritative
  server, again, IETF typically does not tell endpoints how they have
  to be configured.
  
* Should we do lazy probing, like PowerDNS Recursor does, or
  use the more eager "happy eyeballs" algorithm of the current draft?
  
Also, currently, regarding the possible warning to system
administrators about the need for 53 and 853 to be in sync, we
currently find in the wild servers that implement different services on
the two ports. See for instance ns1.eu.org (authoritative for eu.org)
or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both
have authoritative on 53 and an open resolver on 853. Should we
explicitely ban this practice?

You may find some details of this work during the hackathon on my article:

https://www.bortzmeyer.org/hackathon-ietf-116.html

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 02:32:46PM +0100,
 Jim Reid  wrote 
 a message of 13 lines which said:

> > RFC 7626 (the threat model and problem analysis that some people
> > claim is missing) is clear (section 2.5.2 for instance).
> 
> RFC7626 is 6 years old.

RFC 793 is 39 years old. Let's drop TCP and move to QUIC (the RFCs are
in the RCF-EDITOR state).

And I'm too charitable to mention the age of DNS RFCs.

> It predates the DoH and DoT (and soon DoQ) specs.

So what? 

> Some other risks have changed since 2015 too.

Please be specific and mention them.

> It’s not your fault that fine RFC has been OBE. :-)

I don't remember receving it from Elisabeth II


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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 10:12:52PM +,
 Andrew Campling  wrote 
 a message of 30 lines which said:

> My apologies if the stance of TLD operators is well known to most in
> this group,

I don't think so, this they are a very diverse group, working under
very different conditions.

> do sufficient TLD operators believe that it needs to be solved

Also, it is not just a matter of the operators of a TLD, every TLD has
a consistuency [add various words like "stakeholders" here] which may
have opinions, too.

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 11:43:57PM +0200,
 Bill Woodcock  wrote 
 a message of 74 lines which said:

> This isn’t a place for pointless thrashing around as a byproduct of
> someone’s unrelated agenda.  Which was, I think, the point of the
> statement.

But I wonder again who this "someone" is? I don't remember ever seeing
some one or some organization saying (at least publically) "root name
servers must support encryption of DNS queries now".

That's why the root server operator statement surprised me. They very
rarely issue collective statements. What were they replying to?

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 02:12:03PM +0100,
 Jim Reid  wrote 
 a message of 15 lines which said:

> But the WG doesn’t seem to want to consider that.

But what DPRIVE could do here? RFC 8806 is published. Besides sending
its successor on the standards track, what do you suggest the group to
do?

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 03:15:14PM +0200,
 Vladimír Čunát  wrote 
 a message of 11 lines which said:

> So far I haven't noticed anyone pushing for encryption to the root.

Indeed. And this is why the root server operators statement is
surprising. It looks like a reply to some pressure to encrypt,
pressure that I saw nowhere.

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 01:00:43PM +,
 Hollenbeck, Scott  wrote 
 a message of 38 lines which said:

> [SAH] Why assume that encryption is required to provide confidentiality?

We never assumed that. RFC 7626 (the threat model and problem analysis
that some people claim is missing) is clear (section 2.5.2 for
instance).

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 10:44:08AM +0200,
 Vladimír Čunát  wrote 
 a message of 12 lines which said:

> it's not so difficult to completely avoid querying root servers,
> through one of the "local root" approaches.

RFC 8806 does not seem mentioned in the statement. Does anyone know
why? 

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Tue, Mar 30, 2021 at 05:53:59PM -0700,
 Erik Kline  wrote 
 a message of 111 lines which said:

> I think, "IN NS com." doesn't reveal much information.  But perhaps
> "IN NS sensitive-tld." could have privacy implications for some
> folks?

ir? cu? gay?

Also, while com/NS will be in the resolver's cache most of the time,
some small TLDs won't, so the request may be more easily correlated
with other activity.

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Tue, Mar 30, 2021 at 05:19:29PM -0700,
 Rob Sayre  wrote 
 a message of 69 lines which said:

> The DNSSEC stuff stood out to me. Why is that even seen as something that
> would help?

Because one of the ways to improve privacy at the root is local
synthesis of answers by the resolver, following RFC 8198, and it
depends of DNSSEC. (Otherwise, we could just use RFC 8020.)

True, it will work only for non-existing domains, which may not be too
revealing but it is just one of the recommended ways, the other being
QNAME minimisation (which does not depend on DNSSEC).

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

Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

[Stephane Bortzmeyer]

On Tue, Mar 30, 2021 at 05:00:29PM -0700,
 Rob Sayre  wrote 
 a message of 56 lines which said:

> Why can't "The Root Server Operators" run QUIC etc as well as their
> existing UDP methods?

Just a note that DNS-over-QUIC is far from standard
currently. 
Unlike Dot and DoH.


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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

[Stephane Bortzmeyer]

On Mon, Nov 02, 2020 at 02:54:13PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 43 lines which said:

> Title   : DNS Privacy Requirements for Exchanges between 
> Recursive Resolvers and Authoritative Servers
> Authors : Jason Livingood
>   Alexander Mayrhofer
>   Benno Overeinder
>   Filename: draft-ietf-dprive-phase2-requirements-02.txt

> 9.1 there are currently three ways to reduce that exposure:

ECS should be mentioned here, as a "fourth way" (or may be just a
reference to RFC 8932).

> 9.2. Operators of authoritative services have to provide stable and
> fast DNS services, and interact with a wide range of clients, not
> all of them authoritative servers.

I don't understand the sentence. Except for NOTIFY/AXFR, the
authoritative name servers do not interact with authoritative name
servers, they talk mostly to resolvers (plus the CS students probing
them with dig). 



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

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

[Stephane Bortzmeyer]

On Wed, Nov 04, 2020 at 02:15:03AM +,
 Paul Hoffman  wrote 
 a message of 114 lines which said:

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

Nevertheless, hints from the authoritative name server can be useful,
such as "You should use DoT in strict mode but there is also a DoH
service which is quite experimental with a self-signed
certificate". Other IETF protocols have such hints from the
authoritative side about what the client should do, even if they
cannot be enforced (RFC 7208 for instance).

Is it worth the complexity? I don't know but it is not useless.



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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

[Stephane Bortzmeyer]

On Mon, Nov 02, 2020 at 02:54:13PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 43 lines which said:

> Title   : DNS Privacy Requirements for Exchanges between 
> Recursive Resolvers and Authoritative Servers
> Authors : Jason Livingood
>   Alexander Mayrhofer
>   Benno Overeinder
>   Filename: draft-ietf-dprive-phase2-requirements-02.txt

In 5.1, items 2 and 3 may require some clarification. For instance, "A
recursive resolver that supports recursive-to-authoritative DNS
encryption MUST be able to determine whether or not a given
authoritative name server to which it intends to connect also supports
recursive-to-authoritative DNS encryption." An obvious way to fulfill
this requirment is to try to start TLS on port 853 and see if it
works. But I guess item 2 was instead about the ability to determine
IN ADVANCE, before connecting, if encryption is supposed to be
supported? 



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

Re: [dns-privacy] Fw: New Version Notification for draft-yan-dprive-local-service-indication-02.txt

[Stephane Bortzmeyer]

On Mon, Jul 13, 2020 at 10:17:57AM +0800,
 Z.W. Yan  wrote 
 a message of 120 lines which said:

> The motivation of this draft is to actively indicate the privacy
> protection capability of the recursive server.

The approach in draft-ietf-dnsop-resolver-information seems better since:
* it is more general, not limited to privacy,
* the information is sent by the resolver itself, who probably knows
 better than the DHCP server.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-13.txt

[Stephane Bortzmeyer]

On Fri, Jul 10, 2020 at 09:41:07AM +0100,
 Sara Dickinson  wrote 
 a message of 61 lines which said:

> This version should address the final comments from the IESG review.

Some very small editorial details:

Abstract "to assist writers of a Recursive operator Privacy statement"
Capital S, for the acronym.

Section 1 "These open resolvers have tended" Rather "public resolvers"
to be consistent with the rest of the paragraph and with RFC 8499.

Section 5.3.1 "Run a copy of the root zone on loopback [RFC7706]"
should now be written "Run a local copy of the root zone [RFC8806]".

Appendix D.2 "Both POST and GET are supported" Can probably be deleted
since RFC 8484 says "DoH servers MUST implement both the POST and GET
methods."


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

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

[Stephane Bortzmeyer]

On Mon, May 11, 2020 at 12:35:11PM -0700,
 Christian Huitema  wrote 
 a message of 294 lines which said:

> The paragraph in section 5.1 seems to imply that embedding a
> recursive resolver in the end point or close to reduces the privacy
> attack surface:

Note that it was already in RFC 7626 (which does not mean it was
right). I agree with you that there is a weakness in the reasoning (a
sniffer located between such a resolver and the rest of the Internet
would see a lot since a one-user resolver may have little caching).

I think the problem is that the RFC (in 7626-ter?) should better
separate upstream surveillance (before the resolver), downstream
surveillance (after the resolver) and internal surveillance (inside
the resolver). Using a in-host resolver decreases upstream
surveillance and suppresses internal surveillance, but does little for
downstream surveillance (because of limited caching). Using a remote
resolver with DoT or DoH to reach it may expose to internal
surveillance (if the trust in this resolver is misplaced) but
decreases upstream and downstream (because of caching) surveillance.

> At a minimum, I would like to see a forward pointer to section 6.2
> in the recursive resolver on device paragraph. A general warning
> that this is a trade-off would be nice too.

I agree and I suggest "As it is often the case with privacy, there is
a trade-off here. A local (to the user's machine or LAN) resolver
reduces the risk that the resolver's administrator read the user's DNS
traffic, but it does not protect a lot against later sniffing, done at
the place where the resolver talks with authoritative name servers."

> I found the discussion of application embedded resolvers bizarre.

See 

I know think that it is indeed on the wrong track.

> In a modern environment, the concept of host is very fuzzy. We get all
> kinds of special devices. We also get containers or virtual machines
> running inside hosts. A browser is in practice such a container.

I agree that OSvsApplication it should not be in this draft.

> As for section 6.1.1.2, I would scratch most of it,

I completely agree.

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

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

[Stephane Bortzmeyer]

On Tue, May 12, 2020 at 02:14:43PM +0200,
 Vittorio Bertola  wrote 
 a message of 144 lines which said:

> Every time the authors put the effort to rewrite it once again
> according to the comment, and every time a new comment comes in
> saying that this is not enough. I admire their patience.

Not "the authors", just Sara, she was the one patient and
hard-working, the other author was lazy.

> I think this section has already been rewritten at least half a
> dozen times, and every time there was a claim that it is not neutral
> (sometimes even on text that previously seemed to be ok).

Yes, and I think I know now the root of the problem. 7626bis tries to
go too far and, instead of discussing the DNS protocol and its privacy
issues, now goes into end hosts and discuss what is done inside the
machine, and what should be done. This is certainy interesting, and it
certainly has consequences on privacy, user control, etc but:

1) It is a bit outside IETF's domain, since it is not inside the
network,
2) There is clearly no consensus inside IETF about it.

My personal opinion is now that the best way out of the problem is to
drop discussions about internal (to the end host) issues.

> These privacy impacts, even if with very variable views, have been
> the subject of many conferences, articles and talks in the last
> couple of years

Which clearly demonstrated that there is no consensus about it.

> You seem to miss the point, which is not about users setting their
> preferred resolver at the application level, but about applications
> that by default ignore the resolver settings in the device and pick
> their own preferred resolver independently from the user.

There is zero difference between an user using the resolver configured
in the OS and the user using the resolver configured in the
application. In both cases, the user uses the default value, not
knowing how to change it or if he/she should change it, or even that
it exists.

Also, Christian is right here: there is no clear definition of OS
vs. application and creating one seems to me quite outside of IETF's
realm.

> I am also puzzled by the fact that this draft was actually in last
> call six months ago, and it only received a single objection just
> before the deadline, and since then we have entered an endless cycle
> changing it again and again and again. I did my best to help with
> compromise text as requested but I do not understand where this
> process is going.

See my suggestion: IETF should stop discussing relationship between OS
and apps (which is fuzzy, anyway) and should focus on network
protocols.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-bcp-op-09.txt

[Stephane Bortzmeyer]

On Mon, May 04, 2020 at 01:06:10PM -0400,
 Bob Harold  wrote 
 a message of 156 lines which said:

> 7.1.2.  Trust Model Bootstrapping
> 
> The whole first paragraph is difficult to parse - it does not seem like
> complete sentences.

Do we talk about the same draft? There is no "7.1.2.  Trust Model
Bootstrapping" in draft-ietf-dprive-bcp-op-09.txt.

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-00.txt

[Stephane Bortzmeyer]

On Sun, Dec 15, 2019 at 07:33:04AM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 35 lines which said:

> Title   : DNS Privacy Requirements for Exchanges between 
> Recursive Resolvers and Authoritative Servers
> Authors : Jason Livingood
>   Alexander Mayrhofer
>   Benno Overeinder
>   Filename: draft-ietf-dprive-phase2-requirements-00.txt

>  3.   Use a secure transport protocol between a recursive resolver and
>TLD servers
>
>   4.   Use a secure transport protocol between a recursive resolver and
>the root servers

It is not clear why there is a specific requirment for root and TLD
auth. servers. Why not just "Use a secure transport protocol between a
recursive resolver and the authoritative nameservers"? Is it because
it is not expected that example.com or other SLD won't have secure
transport soon?

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

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

[Stephane Bortzmeyer]

On Thu, Jan 09, 2020 at 10:29:29AM -0800,
 Eric Rescorla  wrote 
 a message of 181 lines which said:

> > It means a standards compliant DoT implementation will have no
> > client identifiers, a standards compliant DoH implementation is
> > free to (and likely) to include them.
> >
> 
> [Citation needed]

I'm not sure I understand your remark. Do you mean that Sara's
sentence should be backed up with specific references? I mean, since
DoH is HTTP and HTTP (unlike DNS) has a lot of headers that, together,
can identify a client, is it enough to reference HTTP RFCs to support
the claim?

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

Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC

[Stephane Bortzmeyer]

On Wed, Jan 01, 2020 at 10:45:58PM -0800,
 S Moonesamy  wrote 
 a message of 63 lines which said:

> There are currently four (IETF) working groups focused on DNS with three of
> them having privacy as part of their charter.

doh, dnssd and dprive (plus dnsop)?

> Section 1 of the draft has a tutorial of how DNS works.  What is the
> audience for this draft?

People (mostly at the IETF) interested by DNS privacy. When preparing
RFC 7626, we saw that many IETF participants had fuzzy (and sometimes
wrong) ideas about the DNS so this introduction seems a good idea.

> Section 3.1 of the draft discusses about the claim that "the data in the DNS
> is public".  The claim is supported [1] by one of the authors of the
> draft.

It is indeed an important tenet of the draft (as it was for RFC 7626).

> The draft states that the claim makes sense.  What is the meaning of the
> "data in the DNS"?

I'm confused. Is it a real question? Anyway, it proves that a tutorial
on the DNS is useful :-) So, "data" is the content of the Answer,
Additional and Authority sections in the answer. RFC 7626, section
2.1.

> The choice of resolvers was previously made by the network on which
> the user was connected.

No. (If you say Yes, please quote the relevant RFC.) DNS is a
protocol, the way a machine provisions its resolver(s) is out of scope.

> Recently, the Internet Engineering Steering Group approved the
> standardization of a mechanism so that the choice can be made by a
> web browser.

That's a very serious misrepresentation of DoH. Counter-example:
Google Chrome did DNS resolution with UDP, a long time ago. 

> The data from the DNS query is, with some exceptions, automatically
> transferred to a foreign jurisdiction.

Again, it seems you don't know the difference between a protocol and
an implementation.

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

Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Stephane Bortzmeyer]

On Tue, Jan 07, 2020 at 02:47:02PM -0800,
 Eric Rescorla  wrote 
 a message of 310 lines which said:

> Yeah, my point is that I don't agree with this. Right now there is a
> lot of ISP centralization and the move of some of that traffic to
> public resolvers potentially decreases centralization at the margin.

Also, when we document SMTP issues, do we mention the current
centralisation in a few email providers? I don't think so. Therefore,
why doing it for the DNS?


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

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Stephane Bortzmeyer]

On Tue, Jan 07, 2020 at 06:37:38PM +,
 Sara Dickinson  wrote 
 a message of 278 lines which said:

> There is currently no standardized discovery mechanism for DoH and
> Strict DoT servers so applications that might want to dynamically
> discover such encrypted services are not able to. At the time of
> writing, efforts to provide standardized signalling mechanisms for
> applications to also discover the services offered by local
> resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing
> numbers of ISPs are deploying encrypted DNS, for example see the
> Encrypted DNS Deployment Initiative [EDDI]."

I disagree with this text, since it seems to imply that a discovery
mechanism would be a good thing. I suggest instead that any discovery
mechanism threatens the goal of DoE (DNS over Encryption) since it
could be easily used to direct users to a resolver which they disagree
with (for the same reason, DoH on Internet Access Providers is not
very interesting since, if you trust your access provider, you don't
really need DoE).

The point of DoE is to be able to have a secure link to the resolver
you decided to trust. If we are to mention discovery, I demand that
the text should be more neutral, not implying that we are missing
something.

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

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

[Stephane Bortzmeyer]

On Tue, Jan 07, 2020 at 06:39:18PM +,
 Sara Dickinson  wrote 
 a message of 194 lines which said:

> > on the basis that it assumes that these optimizations are deployed
> > without regard to privacy.

May be just an informative reference to RFC 7231, specially section
9.7, would please everyone? This section seems quite comprehensive on
the issue of privacy leaks from HTTP headers.

> “the wide practice in HTTP to use various headers to optimize HTTP
> connections, functionality and behaviour which can introduce a
> trade-off between functionality and privacy

Most of the time, as noted by RFC 7231 in its section 3.4.1, the
privacy leaks bring no added functionality and no optimisation.



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

[dns-privacy] DNS stamps

[Stephane Bortzmeyer]

Could be useful specially for secure and public resolvers, may be
worth of some IETF work?

https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps

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

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

[Stephane Bortzmeyer]

On Wed, Nov 27, 2019 at 10:04:57AM +,
 Neil Cook  wrote 
 a message of 45 lines which said:

> I don’t see why they’re broken by design;

You explained it well:

> they add no security properties

> on top of the (insecure) DHCP mechanism used to contact the resolver
> in the first place

And the problem is not the (in)security of DHCP. The problem is that
if you don't trust the access network to provide you with a secure
resolver, why would you trust it to indicate one? If the default
resolver (DNS over UDP, obtained through DHCP) lies or records
personal data, why would the resolver found by "resolver discovery" be
better?

> how clients use that information is up to them. They may or may not
> decide to trust that resolver,

OK, if it is clearly specified, I understand. But it is far from
clear, for instance in draft-reddy-dprive-bootstrap-dns-server.

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

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

[Stephane Bortzmeyer]

On Wed, Nov 27, 2019 at 09:07:15AM +,
 Konda, Tirumaleswar Reddy  wrote 
 a message of 72 lines which said:

> > *All* "automatic discovery of the DoH resolver" schemes are broken
> > by design and I really wonder why people keep suggesting them.
> 
> Not all discovery mechanisms have security holes, you may want to
> look into
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05.

It seems to me that this draft has exactly the same problem as every
other "resolver discovery" proposal: it gives complete power to the
access network to indicate the resolver to use. If you use DoH/DoT, it
is because you don't trust the access network. Relying on it to
indicate a DoH/DoT resolver is pointless.

For instance, if your access provider has a lying resolver and you
want to escape it with DoH/DoT access to an external resolver, I don't
see how this draft helps you.

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

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

[Stephane Bortzmeyer]

On Tue, Nov 26, 2019 at 09:51:14AM -0800,
 Brian Dickson  wrote 
 a message of 98 lines which said:

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

I'm not sure I understand the problem. This case is just an instance
of a more general problem "the machine you talk with may betray you
and no amount of cryptography will help here". The resolver can send a
copy of all your requests to the NSA (or its chinese equivalent), or
it could use a forwarder over an unencrypted connection. What's the
difference?

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

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

[Stephane Bortzmeyer]

On Tue, Nov 26, 2019 at 12:35:13PM -0500,
 Phillip Hallam-Baker  wrote 
 a message of 166 lines which said:

> 2) Admin/User Configured DNS
> The client obtains the information to connect to a resolver through an
> Administrator or User configuration action. This may be inserting an IP
> address (8.8.8.8/1.1.1.1/etc) or some form of DNS label.
> 
> 3) Application/Platform Provider Configuration.
> The application or OS platform can simply ignore user preferences and
> choose a DNS provider of its own liking.

Note that, for free software, there is no real difference between 2)
and 3). Someone can always change the source and recompile. (And there
is of course no real privacy without free software.)

> But please, assure me that we are not the brink of users being faced
> with pop ups asking them 'would you like to choose me as your DNS
> provider'.

Why not? But, anyway, the IETF does not do UI so it's not really our
job.

> Of these three models, I have always considered (1) to be a security
> hole.

I fully agree. *All* "automatic discovery of the DoH resolver" schemes
are broken by design and I really wonder why people keep suggesting
them.

> So what I see is a requirement for DNS resolver configuration. We
> already have rfc6763 to tell us how to get from a DNS label to an
> Internet service.  Albeit one that presupposes the existence of a
> resolution mechanism. I don't see it being problematic to use the
> local DNS to do this resolution provided that 1) we have the means
> to authenticate the connection and 2) we only use this mechanism
> once, to perform initial configuration.

I agree too. A simple _doh.MYDOMAIN.example/SRV request would
suffice. (Even better, HTTP should support SRV, but I digress...)

___
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

[Stephane Bortzmeyer]

On Wed, Nov 06, 2019 at 01:16:29PM +,
 Sara Dickinson  wrote 
 a message of 241 lines which said:

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

Not too 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.”?

OK, fine.

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

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

[Stephane Bortzmeyer]

On Mon, Nov 04, 2019 at 08:20:05AM -0800,
 Tommy Pauly  wrote 
 a message of 45 lines which said:

> However, there are a couple reasons we're interested in having DoH
> servers directly support receiving Oblivious queries:

Ok, but these reasons should be put in the draft (may be in an
appendix), to avoid repeated questions.

> Tor is also meant as a generic connection-level anonymity system,
> and thus seems overly complex for the purpose of proxying a
> request/response protocol such as DNS.

On the other hand, it has been well-examined, well-checked and
well-attacked so we know the trust we can put in it. A new
cryptography protocol is always risky.

There have been exactly the same discussion at the beginning of DPRIVE
about the encryption layer for DNS. The proponents of TLS (which won,
and gave RFC 7858) mentioned the fact that TLS was battle-hardened and
well studied, the adversaries preferred a more DNS-friendly protocol,
such as draft-wijngaards-dnsop-confidentialdns.


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

Re: [dns-privacy] ADoT signalling

[Stephane Bortzmeyer]

On Sun, Nov 03, 2019 at 05:33:34PM -0500,
 John Levine  wrote 
 a message of 14 lines which said:

> I thought it might be useful to make a list of possible ways to signal
> that a server offers ADoT:

I would like also a discussion on whether signaling is 1) good 2)
necessary.

Even if you get a signal, the reality may be out-of-sync with the
signal, for instance because of a problem on the server side (remember
s published without checking IPv6 connectivity works) or on the
client side (port 853 blocked). So, in any case, the client has to be
ready to encounter a problem and to try a fallback.

So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
more or less in parallel and keep DoT if it works.


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

Re: [dns-privacy] ADoT signalling

[Stephane Bortzmeyer]

On Sun, Nov 03, 2019 at 05:33:34PM -0500,
 John Levine  wrote 
 a message of 14 lines which said:

> I thought it might be useful to make a list of possible ways to signal
> that a server offers ADoT:
> 
> https://datatracker.ietf.org/doc/draft-levine-dprive-signal/
> 
> I'm sure there are others, feel free to send suggestions.

Well, some more were mentioned in draft-bortzmeyer-dprive-step-2 some years ago:

1) DANE (used as a signaling tool)

2) "reverse" DNS
3.5.0.0.1.0.0.0.0.0.0.0.0.0.0.0.e.f.a.c.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN TXT 
"I do DoT"

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

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

[Stephane Bortzmeyer]

On Fri, Nov 01, 2019 at 03:40:51PM -0700,
 Tommy Pauly  wrote 
 a message of 393 lines which said:

> We've posted new versions of our drafts on discovering designated DoH 
> servers, and Oblivious DoH:

If you want to separate the knowledge of the source IP address and the
knowledge of the QNAME, I still don't understand what is the point of
Oblivious DoH when we can simply connect to the DoH resolver over
Tor. This really deserves an explanation in the draft.

___
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

[Stephane Bortzmeyer]

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.

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.

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

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

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

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

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

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

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

[Stephane Bortzmeyer]

On Tue, Mar 12, 2019 at 04:55:11PM +0100,
 Neil Cook  wrote 
 a message of 22 lines which said:

> Actually many enterprises (particularly banks etc.) do not allow DNS 
> resolution directly from employee endpoints.

They block UDP/53, which is not the same thing. Malware or
non-cooperating applications can do name resolution by other means. I
still do not understand why people have a problem with DoH whch did
not already exist before with
my-own-name-resolution-protocol-over-HTTPS.

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

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

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 11:17:43PM -0700,
 Paul Vixie  wrote 
 a message of 36 lines which said:

> > You claim the right to impose your rules, because it is "your network".
> > Yet you have to define ownership.

> my network, my rules. your provider's network, their rules.

I clearly disagree. If the case of my home network (mine, my rules) is
clear, the case of a corporate network is less clear (an employee is
not a slave, and he/she has rights) and the case of a commercial
Internet access provider is clear in the other direction: a client is
not an employee, and is entitled to a free, open and neutral Internet
access.

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

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

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 09:59:11AM +0530,
 nalini elkins  wrote 
 a message of 231 lines which said:

> Companies also (validly, in my opinion) wish to know if their
> employees are going to fantasyfootballgame.com while they are
> supposedly doing work and of course, other sites which people should
> not be going to during work time.  If I am paying someone, I expect
> them to do work that I wish them to do.

Not all companies work that way. Some evaluate the work done by the
results, not by the time spent at the desk. Please let's not discuss
IETF protocols while assuming that all companies are the same, and
that we have to endorse all their policies.

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

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

[Stephane Bortzmeyer]

On Sun, Mar 10, 2019 at 10:24:56PM -0700,
 Paul Vixie  wrote 
 a message of 82 lines which said:

> set up a war between end users and network operators,

Well, the tussle already exists. It does not depend on whether you
like it or not, on whether the IETF approves it or not. When people
have different interests, there is a tussle. What we can hope is to
discuss it in civilized ways. But we cannot make it disappear.

 

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

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

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 08:55:18AM +0530,
 nalini elkins  wrote 
 a message of 202 lines which said:

> The questions that the Fortune 50 company architect asked were something
> like this:
> 
> 1. You mean that DNS could be resolved outside my enterprise?

I suggest to explain to this person that it was possible before, as
any malware author discovered.

> 2. So whoever that is that resolves my DNS sees the pattern and frequency
> of what sites my company goes to?

RFC 7626 :-)

> It would be good to also discuss how to warn enterprises that this
> is about to happen.  I wonder if an announcement via CERT or another
> group may be appropriate.

If people responsible for networks of Fortune 50 company don't know
that it is difficult to stop unwanted communication (except when you
control all the endpoints, or when you airgap your network), then it
is indeed a problem :-)

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

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

[Stephane Bortzmeyer]

On Tue, Mar 12, 2019 at 08:14:49PM +1100,
 Mark Nottingham  wrote 
 a message of 32 lines which said:

> I'm also very conscious that we had a side meeting about similar
> issues in Singapore (IIRC), and didn't make much progress at all in
> that time.

This time, we have drafts (poor ones, IMHO, but it's better than a
discussion without written proposals).

> Are we going to be able to productively use two hours for this?
> Could we come up with a more focused agenda and just use an hour?

You are the first to suggest to focus, until now, all remarks (both on
and off-list) have been people asking to *enlarge* the agenda :-)

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

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

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 06:57:03PM +0100,
 Vittorio Bertola  wrote 
 a message of 18 lines which said:

> Moreover, centralization is not the only Do*-related problem
> category that has been raised (my draft alone lists eight others).

IMHO, this is precisely the biggest problem with these three drafts:
they accumulate a lot of unrelated rants, and it is important to split
between issues that are really DoH-specific from more general issues.

Warren Kumari did a good job of sorting that out in
. I
quote him:

1: the protocol,
2: the deployment concerns,
3: "resolverless DNS",
4: the loss of visibility from encrypting the DNS

IMHO, this makes several side meetings. People are welcome to organize
more.

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

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

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 01:59:25PM -0400,
 Allison Mankin  wrote 
 a message of 94 lines which said:

> Perfect idea, very good use of the Wednesday slot.

New date and place registered at
,
wednesday, Karlin 1/2, 1500 to 1700. (Note there is registry lock side
meeting just before, for domain name industry people.)

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

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

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 10:06:21AM -0700,
 Ted Hardie  wrote 
 a message of 76 lines which said:

> This conflicts with SECDISPATCH, which will have a pretty serious impact on
> who might attend.  Scheduling these things is very hard, obviously. Given
> this topic, you may have to move outside the normal agenda time to get a
> reasonable shot at avoiding conflict.

I avoided conflicts with doh, dprive, dnsop and hrpc but avoiding all
conflicts is close-to-impossible. In the evening, people have
meetings, too.

I admit I'm not sure that Secdispatch is so important here. The
subject of the side meeting is not security-specific.

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

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

[Stephane Bortzmeyer]

[Resent with the correct list of working groups.]

[Sorry for the long list of working groups but the discussion already
started in different places.]

There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484)
deployment and the risk of centralization of Internet services. (See
for instance drafts [this is not an endorsement]
draft-bertola-bcp-doh-clients, draft-reid-doh-operator and
draft-livingood-doh-implementation-risks-issues.)

It was suggested Reference necessary to have a
side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
Tyrolka. The proposal is at
. You
are welcome to agree/disagree/meet in a bar instead.

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

Re: [dns-privacy] DoT between recursive and authoritative pilot

[Stephane Bortzmeyer]

On Fri, Dec 21, 2018 at 06:59:43PM -0800,
 manu tman  wrote 
 a message of 43 lines which said:

> As some you already know, Cloudflare and Facebook have been running a pilot
> on using DoT between Cloudflare DNS and Facebook authoritative name servers.
> You can read more about it at
> https://code.fb.com/security/dns-over-tls/

Thanks. Very useful.

I do not find how the Cloudflare resolver discovers that Facebook
authoritative name servers use DNS-over-TLS, and what are their
keys. Hardwired in the resolver for the experiment?

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

[dns-privacy] Is there a draft for Knot "Experimental DNS-over-TLS Auto-discovery"

[Stephane Bortzmeyer]

was already mentioned in the discussion about encoding keys in
names. But is there a draft for this trick? I cannot find one.

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

Re: [dns-privacy] Fwd: New Version Notification for draft-annee-dprive-oblivious-dns-00.txt

[Stephane Bortzmeyer]

On Sat, Jul 14, 2018 at 09:13:56PM -0400,
 Nick Feamster  wrote 
 a message of 40 lines which said:

> 1. Tor is vulnerable to DNS fingerprinting, particularly at the
> recursive resolver. Many Tor exits use Google public DNS (~40%, by
> exit throughput),

I know this research but I don't see the point. You typically connect
to your DoH or DoT resolver by IP address so the resolver used by the
exit node is irrelevant.

(Also, if you use a .onion, there is no exit node.)

> 3. Tor and .onion in particular have some pretty serious usability
> problems.

Users typically don't interact directly with their DNS resolver,
unlike they like to use dig so, again, I don't see how it is related
to the problem.

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

Re: [dns-privacy] Fwd: New Version Notification for draft-annee-dprive-oblivious-dns-00.txt

[Stephane Bortzmeyer]

On Tue, Jul 03, 2018 at 06:18:51PM -0400,
 Ben Schwartz  wrote 
 a message of 293 lines which said:

> My main question for the authors is: how does this compare to
> routing a DNS-over-TLS socket through a TCP forwarder?

Isn't it what Tor is doing? Reasons to use Tor:

* well known and studied, privacy-wise
* there is even a public DoH resolver in .onion
  

My first feeling about Oblivious DNS is that it looks like a
reinvention of Tor, specific to the DNS.

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

[dns-privacy] RIPE Atlas probes can now test DNS-over-TLS

[Stephane Bortzmeyer]

The RIPE Atlas probes, really useful for testing Internet servers from
several vantage points, can now do DNS-over-TLS.

Starting with version 1.1.4, the blaeu program (article in
,
source code and issue tracker in
) can exploit this feature:

Without TLS:

% blaeu-resolve --nameserver 9.9.9.9 --displayrtt  www.ietf.org
Nameserver 9.9.9.9
[2400:cb00:2048:1::6814:155 2400:cb00:2048:1::6814:55] : 5 occurrences Average 
RTT 298 ms
Test #14440420 done at 2018-06-16T07:10:53Z

With TLS, on the same Atlas probes (note the different RTT):

% blaeu-resolve --nameserver 9.9.9.9 --displayrtt --tls --old_measurement 
14440420  www.ietf.org
Nameserver 9.9.9.9
[2400:cb00:2048:1::6814:155 2400:cb00:2048:1::6814:55] : 5 occurrences Average 
RTT 2806 ms
Test #14440421 done at 2018-06-16T07:14:05Z

Unfortunately, the current TLS client in the Atlas probes is a bit old
and does not work with servers which require the very latest TLS 
options/ciphers/etc:

% blaeu-resolve --nameserver 1.1.1.1 --displayrtt --tls   www.ietf.org
Nameserver 1.1.1.1
[TUCONNECT (may be a TLS negotiation error)] : 5 occurrences Average RTT 0 ms
Test #14440463 done at 2018-06-16T07:17:06Z

And of course if the server has no TLS available, it fails:

% blaeu-resolve --nameserver 8.8.8.8 --displayrtt --tls   www.ietf.org
Nameserver 8.8.8.8
[TIMEOUT] : 5 occurrences Average RTT 0 ms
Test #14440464 done at 2018-06-16T07:17:54Z


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

Re: [dns-privacy] dprive - Requested session has been scheduled for IETF 101

[Stephane Bortzmeyer]

On Tue, Feb 27, 2018 at 03:11:25PM -0800,
 "IETF Secretariat"  wrote 
 a message of 45 lines which said:

> dprive Session 1 (1:30:00)
> Wednesday, Afternoon Session I 1330-1500
> Room Name: Balmoral size: 250

Now, we just need an agenda.

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

Re: [dns-privacy] representation of DNS transport in use?

[Stephane Bortzmeyer]

On Sat, Mar 10, 2018 at 08:20:27PM +0900,
 Erik Kline  wrote 
 a message of 165 lines which said:

> TL;DR: Should we have some kind of URI schemes for encrypted DNS
> protocols (i.e. identifying the transport)?

dns+tls: ? (To follow the COAP example of RFC 8323, section 8.)

May be this is a question for uri-rev...@ietf.org?

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

Re: [dns-privacy] Fwd: New Version Notification for draft-dickinson-bcp-op-00.txt

[Stephane Bortzmeyer]

On Tue, Mar 06, 2018 at 10:42:10AM +,
 Sara Dickinson  wrote 
 a message of 198 lines which said:

> There is a new draft (very much a placeholder at the moment) that
> attempts to start the discussion around Best Practices for Operators
> of DNS Privacy Services. It is submitted here for initial review and
> for feedback on the best forum for future versions of this
> document.

I've read  draft-dickinson-bcp-op-00. No strong opinion on the best
forum to discuss it so, in the mean time:

> Other documents that provide further specifications related to DNS
> privacy include [I-D.ietf-dprive-dtls-and-tls-profiles], [RFC7830]
> and [I-D.ietf-dprive-padding-policy].

RFC 7816 is mentioned later but it comes out of the blue, it would
make sense to mention it here.

> In recent years there has been an increase in the availability of
> "open" resolvers.

"Public resolvers" draft-ietf-dnsop-terminology-bis-08: "the term
"public resolver" is used more with open resolvers that are meant to
be open, as compared to the vast majority of open resolvers that are
probably misconfigured to be open"

> 3.1.  General capabilities

Padding (RFC 7830) is not mentioned here (it should).

> A .onion [RFC7686] service endpoint

I don't understand. You mean a public privacy-wise DNS resolver should
be a Tor entry node as well?

>   o  Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the
>  number of queries to authoritative servers to increase privacy.

And NXDOMAIN cut (RFC 8020) as well (specially for the domains without
DNSSEC, or with NSEC3+optout).

> Should we say anything here about filtering responses or DNSSEC
> validation e.g. operators SHOULD provide an unfiltered service on an
> alternative IP address

I would rephrase it as "operators who filters responses SHOULD also
provide an unfiltered service", without mentioning "alternative IP
address", because other means are possible (such as a future EDNS
option "do not lie").

(There is also the possibility of whitelisting *client* IP addresses,
like Cisco OpenDNS does but it is obviously bad for privacy.)

> 3.4.2.  Management of SPKI pins

Is it about generation, security of the private part, or about
publication ("operator MUST publish it on a HTTPS Web page")? Or both?

> 3.4.3.  TLSA records

We should just reference here RFC 7671. 

> 4.2.  Anycast deployments

"Anycast deployments is possible and useful, but we draw the attention
of operators on the fact that it means that, sometimes, IP packets
will come in for an unknown TCP connection, or in an unknown DTLS
session. The service MUST reply with the appropriate message (RST for
TCP) and MUST NOT silently drop such IP packets. They are not
malicious, and are normal for an anycast service."

> 5.  Server data handling

After the paragraph on data retention. "One possibility is to have two
(or more) sets of data, one with a lot of data, but a very short
retention period, intended for daily operations, and one with a longer
retention period, but with less data (source IP addresses shortened,
for instance), intended for analytics."

> TODO: Compare main elements of Google vs Quad9 vs OpenDNS policies

Google 

Quad9 

OpenDNS Cannot find. An URL? The link on their page is just to
, a
general Cisco privacy policy, nothing about DNS.

Google policy and Quad9 policy are very close, to the point where I
suspect copy-and-paste. Google is more detailed on the retention
duration (and they have a temporary/permanent split), Quad9 is more
detailed about the sharing (Google apparently does not talk about
sharing, not even to claim "we don't share").

> 8.  Security considerations

Add "There are no _technical_ means for the user of a privacy-enabled
DNS resolver to check if the operator follows its published
policy. The user must therefore perform his or her assessment, based
on knowledge of the operator, legal or social means to enforce
compliance, etc."




Otherwise, do we recommend or not things like TLS chain extension and
TLS raw keys?

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

Re: [dns-privacy] IETF101 Call for Agenda Requests

[Stephane Bortzmeyer]

On Mon, Feb 19, 2018 at 05:41:33PM -0500,
 Tim Wicinski  wrote 
 a message of 14 lines which said:

> DPRIVE is slated for Wednesday 21 March, 2018  in the first afternoon slot
> (13:30-15:00)
> 
> This is a call for requests for agenda topics.

draft-bortzmeyer-dprive-resolver-to-auth With the idea that, unless
there is actual work on it, it won't go very far. 

> Additionally, we have been discussing a DPRIVE hackathon table. Sara
> Dickinson and I have been talking about this, and there is probably
> something specific shaping up (Sara always knows more,
> we'll have to get with her). Sign up here:
> 
>     http://ietf.org/how/runningcode/hackathons/101-hackathon/

Also, see the ideas in
 You are
welcome to add yours.

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

[dns-privacy] New dnscrypt Web site

[Stephane Bortzmeyer]

https://dnscrypt.info

You'll note that the FAQ  includes a
comparison with IETF solutions. Some remarks:

1) dnscrypt "Cannot be MITM’d by standard tools" vs. DNS-over-TLS
"Readily compatible with industry-standard TLS interception/monitoring
devices"

This seems a strange approach of security. Using non-standard and
little-known tools in the hope there will be less ready-made kits for
script kiddies, works only on a very short term. It is a bit like "I
coded my own CMS in PHP, it is full of security holes but because it
is not the standard Wordpress / Drupal security holes, I'm secure".

2) dnscrypt "Specifically designed for DNS" I'm not sure why it's
counted as a strength…

3) dnscrypt "Post-quantum version in developement"

Buzzword-compliant, for sure but, in the current state of DNS security
(zero encryption most of the time), the problem of quantum computers
breaking RSA, ECDSA and EdDSA is not my biggest concern. Also, TLS may
incorporate post-quantum crypto, no? (For those who want to follow the
IETF work on PQ, see draft-hoffman-c2pq.)

4) DNS-over-TLS "Not well understood even by its proponents" I
confess, I understand nothing to TLS but I assume the RFC 7858 authors
are better than me.

5) DNS-over-TLS "Padding rules haven’t been specified" No longer true
now that draft-ietf-dprive-padding-policy has been submitted to IESG

6) DNS-over-TLS "TLS is a generic transport mechanism. It doesn’t
support reordering and parallelism" It seems they didn't read RFC 7766
(which, alas, is far from being implemented everywhere.)

7) DoH "Uses standard HTTP/2, on the standard port (443)." Not sure it
is a good thing that all the Internet runs over port 443 :-(

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

Re: [dns-privacy] WG Last Call: draft-ietf-dprive-padding-policy-03.txt

[Stephane Bortzmeyer]

On Mon, Jan 22, 2018 at 02:00:16PM +,
 Stephen Farrell  wrote 
 a message of 241 lines which said:

> - Is there any (good) literature on related mechanisms that one
> might use to further increase the difficulties of traffic analysis
> based on DNS traffic? I'm thinking about synthetic cover traffic or
> of adding jitter to the timing of requests, but there could be other
> things one might do. Even if we aren't in a position to provide
> experimental recommendations about such things, (I'd be happy if we
> were), it'd be good to at least add a mention and some references if
> we could. While such work could be done later and in a separate
> specification, it is pretty closely related to this so would also
> fit nicely in here if we had good text to add. (I don't have text to
> offer, sorry.)

I suggest an appendix "Besides padding" with:

It is possible that there are other mechanisms that one might use to
further increase the difficulties of DNS traffic analysis. For
instance, gratuitous queries and/or answers could be added to cover
the real traffic. Or jitter could be added, with a random delay before
replying. We currently don't have enough theoretical analysis or
experimental data to recommend one of these mechanisms.

> - There's no way to know (for sure) which padding scheme a peer is
> using I think?

Local decision, indeed.

> If so, would there be any benefit in making that possible? I think
> the answer is that's there's not enough to gain by doing so.

And it's complicated: there are several policies, each with several
parameters. It would require the standardization of a mini-language,
and of an IANA registry of padding policies.

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

[dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-resolver-to-auth-00.txt]

[Stephane Bortzmeyer]

New Year Resolution for 2018: securing (privacy-wise) the
communication from the resolver to the authoritative name server.

draft-bortzmeyer-dprive-step-2 was not a big success probably because
it was too open, mentinong too many possibilities. Here, I propose
just one method. Comments and criticisms welcome.
--- Begin Message ---

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Encryption and authentication of the DNS 
resolver-to-authoritative communication
Author  : Stephane Bortzmeyer
Filename: draft-bortzmeyer-dprive-resolver-to-auth-00.txt
Pages   : 7
Date: 2018-01-02

Abstract:
   This document proposes a mechanism for securing (privacy-wise) the
   communication between the DNS resolver and the authoritative name
   server.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DPRIVE group, through its mailing list.  The source of the
   document, as well as a list of open issues, is currently kept at
   Github [1].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-dprive-resolver-to-auth/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-00
https://datatracker.ietf.org/doc/html/draft-bortzmeyer-dprive-resolver-to-auth-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--- End Message ---
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

[Stephane Bortzmeyer]

On Fri, Oct 27, 2017 at 11:40:15PM -0400,
 Daniel Kahn Gillmor  wrote 
 a message of 219 lines which said:

> I do not believe that DNSSEC validation is warranted as a mitigation
> against an active attacker in the context of an opportunistic
> metaquery,

I see the point but it seems to me a small detail in a 29-pages
document. So, IMHO, it should not cause yet another long delay for a
draft that already lingered too much.

> But i think the other changes between draft-10 and draft-11 are
> unwarranted and should be reverted.

There are very few changes and, except the DNSSEC *requirment*, they
seem good to me. I agree with Sara "I really do think a description
there of the trade-offs of DNSSEC validation are warranted".

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

[dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked?

[Stephane Bortzmeyer]

The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles
has a DISCUSS "This needs to be updated to indicate that the client
MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise
you're going to have interop problems." The DISCUSS was against -09,
the current version is -11 (1.5 months old) which does address the
problem "A client MUST only indicate support for raw public keys if it
has an SPKI pinset pre-configured (for interoperability reasons)."

Therefore, what's the problem with
draft-ietf-dprive-dtls-and-tls-profiles?

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

[dns-privacy] Android getting “DNS over TLS” support to stop ISPs from knowing what websites you visit

[Stephane Bortzmeyer]

[There was a demo at the Bits-n-Bites in the last meeting, Prague.]

https://www.xda-developers.com/android-dns-over-tls-website-privacy/amp/

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

Re: [dns-privacy] Usage on DNS-over-TLS on IETF Network

[Stephane Bortzmeyer]

On Tue, Jul 18, 2017 at 01:29:27PM +0200,
 tjw ietf  wrote 
 a message of 5937 lines which said:

> Our former co-chair Warren sent us these slides on DNS usage on the
> IETF network and also DPRIVE usage.  It's a small number (but not
> zero!)

It also would be interesting to keep track of TCP sessions: how many
queries per TCP session in average, median duration of TCP sessions,
etc.

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

[dns-privacy] Padding policies draft

[Stephane Bortzmeyer]

draft-ietf-dprive-padding-policy is now expired. Anyone knows what
happens?

I think that the results presented by Daniel Kahn Gillmor at NDSS were
very promising (allowing to base policies on facts).

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

Re: [dns-privacy] Suresh Krishnan's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS)

[Stephane Bortzmeyer]

On Wed, Jun 07, 2017 at 12:25:25AM +0530,
 Suresh Krishnan  wrote 
 a message of 42 lines which said:

> > If so, let me give my opinion: I disagree with the DISCUSS.
> 
> Not sure what you are disagreeing with. Are you saying this text is
> clear about what is needed from the eventual DHCP option(s)?

IMHO, yes.

> The strict profile requires the DHCP server to be “secure and
> trustworthy” but declines to define what it means by “secure and
> trusted”. So I cannot tell if it requires anything from current DHCP
> servers or not.

Proposal for a new 7.3:

In the typical case, a DHCP server [RFC2131] [RFC3315] provides a list
of IP addresses for DNS resolvers (see section 3.8 of [RFC2132]), but
does not provide a domain name for the DNS resolver, thus preventing
the use of most of the authentication methods described here. (All
those that are based on a mechanism with ADN in table 2.)

In the future, a DHCP server might use a DHCP extension to provide a
list of authentication domain names for the offered DNS servers, which
correspond to IP addresses listed. People who wish to work on such a
yet-to-come extension may be interested in section 8 of [RFC7227].

Even with this future extension, this leaves open the issue of the
trust in the DHCP server. Of course, in a typical hotspot, the DHCP
server is not to be trusted (see section 23 of [RFC3315]) for the
Strict profile. When using an Opportunistic profile, it would be
reasonable to use the ADN indicated by the DHCP server, given the
security expectation of that profile.

Some clients may have an established trust relationship with a known
DHCP server for discovering their network configuration.  When using a
Strict profile the DHCP servers used as sources of authentication
domain names is sensible only if the server is considered secure and
trustworthy. This document does not attempt to describe secured and
trusted relationships to DHCP servers, which is a purely DHCP
issue. (Still open, at the time of writing.)  Whilst some
implementation work is in progress to secure IPv6 connections for
DHCP, IPv4 connections have received little to no implementation
attention in this area.

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

Re: [dns-privacy] Suresh Krishnan's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS)

[Stephane Bortzmeyer]

On Tue, May 09, 2017 at 08:43:15PM -0700,
 Suresh Krishnan  wrote 
 a message of 37 lines which said:

> I do have a concern regarding section 7.3 as it is not clear what
> really is being requested on the DHCP front here. While using an IP
> address or an FQDN are generally both possible choices while
> providing configuration options using DHCP, the use of FQDNs for
> acquiring trusted DNS servers seems problematic. We have spent a
> great deal of effort writing up some of the potential issues in
> Section 8 of RFC7227.

It seems there was no reply to this DISCUSS? If so, let me give my
opinion: I disagree with the DISCUSS. Section 7.3 is just here to lay
down some paths toward a future and possible DHCP extension. It does
not attempt to standardize one. It does not request anything from the
current DHCP servers.

Mentioning section 8 of RFC 7227 could help, but this section does not
discuss the DNS-specific issues (such as the fact we need both IP
address and name of the DNS resolver, which RFC 7227 frame it as an
exclusive choice).

Possible solution if it is absolutely necessary to clear the DISCUSS:
moving section 7.3 to an appendix to make clear it is not part of the
DNS-over-TLS profiles definition.

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

[dns-privacy] Nagios/monitoring plugin for a DNS-over-TLS server?

[Stephane Bortzmeyer]

Not yet an official plugin  for
monitoring my DNS-over-TLS server (nothing in
).
Should I develop one at the next hackathon in Chicago? :-)

I assume it is possible/easy with C/getdns and/or Go DNS. I would like
the plugin to:

* obviously, connect to the server over port 853 and issue a given DNS
request and check the result (like check_dig
 does)

* but also be able to test the expiration of the certificate (I plan
to use Let's Encrypt and expiration is a serious concern) like several
monitoring plugins do (like check_http
)

* bonus, being able to force some TLS parameters (minimum version,
etc)

Any idea?

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

[dns-privacy] "SFMap: Inferring Services over Encrypted Web Flows Using Dynamical Domain Name Graphs"

[Stephane Bortzmeyer]

This research (still under embargo) seems relevant to this working group:

 Most modern Internet services are carried over the web. A significant
 amount of web transactions is now encrypted and the transition to
 encryption has made it difficult for network operators to understand
 traffic mix. The goal of this study is to enable network operators to
 infer hostnames within HTTPS traffic because hostname information is
 useful to understand the breakdown of encrypted web traffic. The
 proposed approach correlates HTTPS flows and DNS
 queries/responses. Although this approach may appear trivial, recent
 deployment and implementation of DNS ecosystems have made it a
 challenging research problem; i.e., canonical name tricks used by
 CDNs, the dynamic and diverse nature of DNS TTL settings, and
 incomplete measurements due to the existence of various caching
 mechanisms. To tackle these challenges, we introduce domain name
 graph (DNG), which is a formal expression that characterizes the
 highly dynamic and diverse nature of DNS mechanisms. Furthermore, we
 have developed a framework called Service-Flow map (SFMap) that works
 on top of the DNG. SFMap statistically estimates the hostname of an
 HTTPS server, given a pair of client and server IP addresses. We
 evaluate the performance of SFMap through extensive analysis using
 real packet traces collected from two locations with different
 scales. We demonstrate that SFMap establishes good estimation
 accuracies and outperforms a state-of-the-art approach.


https://hal.archives-ouvertes.fr/hal-01411189v1

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

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[Stephane Bortzmeyer]

On Wed, Dec 14, 2016 at 12:18:17PM +0100,
 Shane Kerr  wrote 
 a message of 87 lines which said:

> So basically you are advocating a model where meta-data
> (specifically lookups of NS records and their associated A/
> records) is public and other data is private?

Not at all. I'm suggesting (see the algorithm in

to switch to opportunistic mode (encrypt but do not try to
authenticate) when retrieving the DANE material. As soon as you get
enough information to authenticate, you go back to strict mode.

This is similar to what is suggested in


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

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[Stephane Bortzmeyer]

On Wed, Dec 14, 2016 at 12:37:39PM +0100,
 Shane Kerr  wrote 
 a message of 65 lines which said:

> If only there was a way to publish information about a server's
> preferences

There is one: DANE (at least to express that you support - or not -
TLS and DTLS).

For UDP and TCP, may be using SRV?


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

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dnsodtls-13: (with DISCUSS and COMMENT)

[Stephane Bortzmeyer]

On Wed, Dec 14, 2016 at 07:43:28AM +,
 Stephen Farrell  wrote 
 a message of 317 lines which said:

> > Yes, will add the above text to a new Section (named "Document
> > Status")
> 
> Great.

I think it is not really necessary, the status Experimental of
draft-ietf-dprive-dnsodtls-13 seemed enough to me.

> > > (2) Section 4: No mention of OCSP stapling?

> > I think the right place to discuss this would be in
> > ietf-dprive-dtls-and-tls-profiles-07#section-8.1,

I fully agree with this opinion.

> Mybe. Be good to cover it there certainly but not sure if that's
> sufficient.

What is missing? draft-ietf-dprive-dtls-and-tls-profiles-07 rightly
avoids to reinvent the wheel and refers to RFC 5280 and RFC 6125. I
don't think it is up to the DPRIVE working group to improve/change
PKIX.


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

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[Stephane Bortzmeyer]

On Tue, Dec 13, 2016 at 11:16:08AM -0800,
 Paul Hoffman  wrote 
 a message of 60 lines which said:

> If what we invent has better characteristics than DTLS or TLS, that
> means that the TLS WG failed to find something that we could. That
> seems *incredibly* unlikely, given the people active in the two WGs.

+1 for me.

It may be that we do something better than the TLS WG because they
have to do something generic, while we can tune for DNS
specificities. Even with that in mind, I'm skeptical we can design a
better protocol without creating new security issues.

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

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[Stephane Bortzmeyer]

On Wed, Dec 14, 2016 at 10:21:13AM +0100,
 Shane Kerr  wrote 
 a message of 90 lines which said:

> > Given that a fallback to TCP/TLS is likely needed even if the
> > right answer is QUIC, and given that however the WG decide to
> > address server authentication and session management should work
> > just as well for TCP/TLS as for QUIC... maybe the WG could
> > experiment with TCP/TLS in the medium term with the longer term
> > plan being to move to QUIC with TCP/TLS as the fallback whenever
> > QUIC seems ready for primetime.
...
> This seems reasonable to me. It basically implies that we should
> insure some small amount of agility in the encrypted channel, which
> seems like a good idea anyway.

I smell practical and programming issues there. Soon,we will have four
ways for a DNS client to talk to a name server, UDP, TCP, TLS+TCP,
DTLS+UDP, and no guidance on how to combine them, in which order to do
so (think of the "happy eyeballs" problem), what to do if some
fail... Adding a fifth, QUIC+TLS, won't help. What will the poor
client be supposed to do?

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

Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?

[Stephane Bortzmeyer]

On Tue, Dec 13, 2016 at 03:22:50PM +,
 Sara Dickinson  wrote 
 a message of 51 lines which said:

> > I'm still a bit concerned about the issue of detection (that there
> > is an attack). Detection for passive attacks is only possible if
> > there is a prior history, unlike the detection for active attacks,

...

> I was trying to indicate that simply using clear text is essentially
> the same as an attack because the traffic _can_ be subject to
> passive eavesdropping.

OK (a bit far-fetched but OK).

> Would it help to replace the “N, D” labels in the table with just
> “N” and update the text to say “N == no protection, may be subject
> to attack”

IMHO, no, since, in some cases, there is really the possibility of a
detection, for instance if a server was doing encryption before and
now refuses, you may suspect an attack (or a downgrade of the
server...)

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

Re: [dns-privacy] [Step 2] More discussion needed: state your opinion

[Stephane Bortzmeyer]

On Tue, Dec 13, 2016 at 03:46:25PM +0100,
 Shane Kerr  wrote 
 a message of 120 lines which said:

> I think that TLS may be more painful in the resolver-to-auth case,
> as TCP Fast Open will be generally less useful, right?

Same thing (even worse) for persistent TCP connections.

But the problem is made less serious by the huge concentration of
authoritative name servers (this concentration is a bad thing, but it
helps for clients who maintain per-server state, which would be the
case with TCP Fast Open). Among the Alexa top 100k, only 24 k servers


> IIRC the idea of using IPsec was also discussed somewhere. IIRC,
> IPsec may have problems traversing NAT. It is also usually
> implemented by the kernel, which may cause deployment issues. I
> *want* IPsec to be an option here, but realistically I don't think
> it is.

Eric Rescorla talked about it at the London BoF


> The other alternative is to invent some novel crypto (fun but
> ill-advised)

This was the opinion defended by Mukund Sivaraman at the Seoul
meeting, and this is why draft-krecicki-dprive-dnsenc is mentioned in
my draft (there is also draft-wijngaards-dnsop-confidentialdns).

> AIUI the draft, if we want to use DNS the problem is that we want to
> know how to encrypt a session to a name server, but we can't look up
> anything about the name server in the DNS because we don't yet know
> how to encrypt a session to the name server.

I disagree. We can look up without keys. It just has to be without
privacy. See for instance the discussion on
draft-ietf-dprive-dtls-and-tls-profiles, specially


> * keys must be shared across administrative boundaries (that is, if
>   I use Dyn and FreeDNS for hosting, then both hosters can
>   impersonate the other or decrypt traffic to the other)

This is for me a stopper.

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

Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?

[Stephane Bortzmeyer]

On Thu, Dec 08, 2016 at 09:51:51AM +,
 Sara Dickinson  wrote 
 a message of 138 lines which said:

> Just to follow up on Tim’s mail. Any reviews of
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ 
>  
> would be much appreciated to try to wind up the WGLC asap.

I've read draft-ietf-dprive-dtls-and-tls-profiles-07 and I've little
to add to what I said in

The points I raised there have been well addressed.

I'm still a bit concerned about the issue of detection (that there is
an attack). Detection for passive attacks is only possible if there is
a prior history, unlike the detection for active attacks, but I have
no concrete suggestion to improve table 1, while keeping it simple to
read.

So, it is OK for me, draft-ietf-dprive-dtls-and-tls-profiles-07 can be
published.

Editorial:

None found



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

[dns-privacy] New version of draft-bortzmeyer-dprive-step-2

[Stephane Bortzmeyer]

 and 853
   to different servers.  Or we may introduce a new delegation RR type,
   PNS (for Privacy Name Server), located only in the child zone (to
   avoid depending on a change of the provisioning software in the
   parent).

5.  IANA Considerations

   There is currently nothing to do for IANA.  The future chosen
   solution may require some IANA action, such as a registry.

6.  Security Considerations

   For the time being, refer to each subsection under Section 3 to have
   an analysis of its security.

   A general problem with all (or most?) encryption protocols will be
   the state to be kept in the server.  It may make some denial-of-
   service attacks easier, of the protocol is not properly designed.

7.  Acknowledgments

   Shane Kerr for the ideas on authentication by IP address.

8.  References

8.1.  Normative References

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
  and P. Hoffman, "Specification for DNS over Transport
  Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
  2016, <http://www.rfc-editor.org/info/rfc7858>.

   [I-D.ietf-dprive-dtls-and-tls-profiles]
  Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
  and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf-
  dprive-dtls-and-tls-profiles-07 (work in progress),
  October 2016.

8.2.  Informative References

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
  RFC 3972, DOI 10.17487/RFC3972, March 2005,
  <http://www.rfc-editor.org/info/rfc3972>.





BortzmeyerExpires May 24, 2017  [Page 7]

Internet-DraftDPRIVE step 2November 2016


   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
  Housley, R., and W. Polk, "Internet X.509 Public Key
  Infrastructure Certificate and Certificate Revocation List
  (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
  <http://www.rfc-editor.org/info/rfc5280>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
  Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
  2012, <http://www.rfc-editor.org/info/rfc6555>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
  of Named Entities (DANE) Transport Layer Security (TLS)
  Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
  2012, <http://www.rfc-editor.org/info/rfc6698>.

   [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
  Transport Security (HSTS)", RFC 6797,
  DOI 10.17487/RFC6797, November 2012,
  <http://www.rfc-editor.org/info/rfc6797>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
  Weiler, S., and T. Kivinen, "Using Raw Public Keys in
  Transport Layer Security (TLS) and Datagram Transport
  Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
  June 2014, <http://www.rfc-editor.org/info/rfc7250>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
  Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
  <http://www.rfc-editor.org/info/rfc7413>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
  DOI 10.17487/RFC7626, August 2015,
  <http://www.rfc-editor.org/info/rfc7626>.

   [I-D.dempsky-dnscurve]
  Dempsky, M., "DNSCurve: Link-Level Security for the Domain
  Name System", draft-dempsky-dnscurve-01 (work in
  progress), February 2010.

   [I-D.krecicki-dprive-dnsenc]
  Krecicki, W., "Stateless DNS Encryption", draft-krecicki-
  dprive-dnsenc-01 (work in progress), October 2015.

   [I-D.ietf-tls-tls13]
  Rescorla, E., "The Transport Layer Security (TLS) Protocol
  Version 1.3", draft-ietf-tls-tls13-18 (work in progress),
  October 2016.




BortzmeyerExpires May 24, 2017  [Page 8]

Internet-DraftDPRIVE step 2November 2016


   [I-D.ietf-tls-dnssec-chain-extension]
  Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
  Record and DNSSEC Authentication Chain Extension for TLS",
  draft-ietf-tls-dnssec-chain-extension-01 (work in
  progress), July 2016.

   [I-D.ietf-dprive-dnsodtls]
  Reddy, T., Wing, D., and P. Patil, "Specification for DNS
  over Datagram Transport Layer Security (DTLS)", draft-
  ietf-dprive-dnsodtls-12 (work in progress), September

Re: [dns-privacy] DPRIVE meeting in Seoul - Friday, Afternoon Session I 1150-1320

[Stephane Bortzmeyer]

On Mon, Oct 24, 2016 at 10:22:07AM +0200,
 Warren Kumari  wrote 
 a message of 20 lines which said:

> Just wanted to let y'all know that we drew the short stick, and have
> been scheduled for Friday afternoon.

But no agenda published yet?

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

Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile

[Stephane Bortzmeyer]

On Thu, Oct 06, 2016 at 02:58:09AM -0400,
 Tim Wicinski  wrote 
 a message of 28 lines which said:

> This starts a Working Group Last Call for:
>draft-ietf-dprive-dtls-and-tls-profile

Executive summary: OK for me,
draft-ietf-dprive-dtls-and-tls-profiles-03 can (and should) be
published. I find that touchy issues, such as the relationship with
the authentication mechanisms described in RFC 7858, or such as the
table 1 "DNS Privacy Protection by Usage Profile and type of attacker"
are nicely done.

The table 1 could use some details about the possibility of detection
for passive attacks (for active attacks, it is addressed in section
5). These details were promised in

:-)

Technical question:

The document seems to use "X.509" and "PKIX" as synonyms. Is it really
the case?

Small legal detail:

> this application [extended to be used for recursive clients and
> authoritative servers] is out of scope for the DNS PRIVate Exchange
> (DPRIVE) Working Group per its current charter.

A bit exaggerated: the current charter says "it [the DPRIVE WG] may
also later consider mechanisms that provide confidentiality between
Iterative Resolvers and Authoritative Servers"

Editorial detail:

> but may be the subject of a future I-D.

Should probably be removed before it becomes a RFC.


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

[dns-privacy] "A Study of Privacy and Anonymity in the DNS"

[Stephane Bortzmeyer]

At the next OARC workshop:

https://indico.dns-oarc.net/event/25/session/5/contribution/26

 A Study of Privacy and Anonymity in the DNS
Speakers

Christopher WOOD

Primary authors

Christopher WOOD (UCI)

Co-authors

Prof. Gene TSUDIK (UCI)
Cesar GHALI (Google)

Content

The need for a private Domain Name System (DNS) has become
increasingly important in recent years. There are several different
proposals to address this growing problem, including DNS-over-TLS and
DNSCurve. The former enables clients to create ephemeral sessions with
either their resolver or authoritative (stub) servers in which queries
can be issued. The latter uses per-query encryption to protect queries
between clients and servers. Encryption is core mechanism used to
enable client privacy in both of these solutions. However, in a recent
study, Shulman showed that encryption alone is insufficient to protect
the privacy of queries. Information leaked in DNS side channels, such
query timing, frequency, and resolution ``chains,'' may reveal the
contents of a query. Moreover, by observing the trust properties of
DNS servers and their responses, an adversary may also learn the
specific record within a domain that was requested.

[...]

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

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

[Stephane Bortzmeyer]

On Wed, Aug 03, 2016 at 03:26:08PM +0200,
 Shane Kerr  wrote 
 a message of 116 lines which said:

> While the draft mentions that resolvers are configured by IP address
> and authoritative servers by name, actually when a resolver is talking
> to an authoritative server it is actually using an IP address.
> 
> That implies a couple of possible solutions:

Added in version -02, thanks.

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

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

[Stephane Bortzmeyer]

On Tue, Aug 16, 2016 at 01:05:40PM -0400,
 Warren Kumari  wrote 
 a message of 38 lines which said:

> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/

I've read it (the last version, -10) and, for me, it is OK, and ready
to be sent to the next step.

I would like to make it a bit shorter by deleting two sentences, "An
active attacker can send bogus responses causing misdirection of the
subsequent connection" in the abstract and "Active attackers have long
been successful at injecting bogus responses, causing cache poisoning
and causing misdirection of the subsequent connection (if attacking A
or  records).  A popular mitigation against that attack is to use
ephemeral and random source ports for DNS queries [RFC5452]." in
section 1. Both are about an attack which is *not* mitigated by
DNS-over-DTLS and these two sentences are clearly out of scope. (The
relationship with DNSSEC, which solves these attacks, is already
handled in section 1.1.)

Otherwise, now that the well-knon port is not absolutely mandatory, I
suggest to change "Once the DNS client succeeds in receiving
HelloVerifyRequest from the server via UDP on the well-known port for
DNS-over-DTLS" to "Once the DNS client succeeds in receiving
HelloVerifyRequest from the server via UDP from the port used for
DNS-over-DTLS".
   
RFC 2119 mandatory flame war: "the DNS client may want to probe the
server using DTLS heartbeat" May or MAY?


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

Re: [dns-privacy] After the DNS-over-DTLS WGLC...

[Stephane Bortzmeyer]

On Fri, Aug 19, 2016 at 04:26:17PM +0100,
 Sara Dickinson  wrote 
 a message of 16 lines which said:

> I couldn’t find a date anywhere - when does the WGLC for
> draft-ietf-dprive-dnsodtls end?

>From the original message by Warren:

This WGLC ends Tue 30-Aug-2016.

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

[dns-privacy] Dowse: "the privacy hub"

[Stephane Bortzmeyer]

For your information. This project is about a future home router
which, by default, tries hard to preserve privacy. One of the
interesting thing for us is that DNS requests are transparently
intercepted by the router, encrypted (with DNScrypt) and sent to a
public resolver.

http://dowse.equipment/

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

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

[Stephane Bortzmeyer]

On Wed, Jul 06, 2016 at 01:54:12PM +,
 Prashanth Patil (praspati)  wrote 
 a message of 61 lines which said:

> The new revision addresses comments received on the list and @IETF-95.

My review of -07 : I see no reason not to move it to WG last call.



Technical :

> DNS client can use the authenication mechanisms discussed in
> [I-D.ietf-dprive-dtls-and-tls-profiles]

> DNSoD client and server can use DTLS heartbeat [RFC6520]

In both cases, the language of RFC 2119 is not used. Is it on purpose?



Editorial:

s/authenication/authentication/




Random thoughts:

Now, a stub resolver may have to try four things (UDP/53, TCP/53,
UDP+DTLS/853 and TCP+TLS/853, all on the Standards track) before
communicating with a resolver. Should we write a meta-document, with
operational guidance, on how this could be done?

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

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

[Stephane Bortzmeyer]

On Tue, Jul 19, 2016 at 12:07:29PM -0400,
 Robert Edmonds  wrote 
 a message of 18 lines which said:

> Why port 953? I thought the registration for the “domain-s” port was
> 853?

It was a bug. It is fixed in the Github repository and the fix will be
published in -01.

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

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

[Stephane Bortzmeyer]

On Tue, Jul 19, 2016 at 11:28:12AM -0400,
 Bob Harold  wrote 
 a message of 63 lines which said:

> why talk to port 953

That was a typo, it will be fixed in -01

> I was assuming normal unencrypted DNSSEC to get the key,

For privacy, encrypted-but-unauthenticated is certainly better (at
least not worse). 

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

Re: [dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

[Stephane Bortzmeyer]

On Tue, Jul 19, 2016 at 11:11:18AM -0400,
 Bob Harold  wrote 
 a message of 130 lines which said:

> I would think that "Key in DNS, authenticated by DNSSEC" would be
> the obvious choice.

It is mentioned, section 2.2.

For the -00 version, I did not try to order ("obvious" or "best") the
choices. Feedback welcomed.

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

[dns-privacy] [internet-dra...@ietf.org: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

[Stephane Bortzmeyer]

Isn't it time we start working on the resolver-to-auth link?

I know that DPRIVE does not meet in Berlin but, if people who are
there (I'm not) want to discuss it, I'll be interested in feedbacks,
flames and pull requests.

--- Begin Message ---

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Next step for DPRIVE: resolver-to-auth link
Author  : Stephane Bortzmeyer
Filename: draft-bortzmeyer-dprive-step-2-00.txt
Pages   : 6
Date: 2016-07-18

Abstract:
   This document examines the possible future work for the DPRIVE (DNS
   privacy) working group, specially in securing the resolver-to-
   authoritative name server link with TLS under DNS.

   It is not intended to be published as a RFC.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DPRIVE group, through its mailing list.  The source of the
   document, as well as a list of open issues, is currently kept at
   Github [1].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-dprive-step-2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-bortzmeyer-dprive-step-2-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--- End Message ---
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Deployment issues

[Stephane Bortzmeyer]

On Mon, Jun 06, 2016 at 09:35:42AM -0700,
 John Heidemann  wrote 
 a message of 53 lines which said:

> Other well approaches are striping queries across multiple servers,
> and adding "chaff" queries.  (I'm not sure that those approaches
> require standardization---they could be done by any interested
> client.)

I would call it "gratuitous queries" instead. Chaffing is for me a
specific technique
. Gratuitous
queries are close to padding, and, like padding, can be hard to do
properly (without allowing retrieval of the interesting
information). A guidance RFC would still be useful even if there is no
protocol change.





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

Re: [dns-privacy] Deployment issues

[Stephane Bortzmeyer]

On Fri, Jun 03, 2016 at 01:33:32PM -0400,
 Paul Wouters  wrote 
 a message of 40 lines which said:

> You would chain various DNS caches together, so a query to one
> populates them all.

Cool idea. We could take inspiration from RFC 2186/2187.


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

Re: [dns-privacy] Recharter discussion? (was DPRIVe Agenda requests for Berlin)

[Stephane Bortzmeyer]

On Mon, Jun 06, 2016 at 07:19:31AM -0400,
 Tim Wicinski  wrote 
 a message of 79 lines which said:

> We started the discussion a few meetings back that we are planning
> on recharting to address the resolver-to-authority session.  We
> (warren and myself) wanted to wait until we've started seeing
> deployment and have gotten some operational data sets that would
> give every the warm fuzzy feelings needed to move along.

In the mean time, if someone is brave enough to write an individual
I-D describing the resolver-to-authority usage of TLS. Distribution of
the keys is of course the biggest difference with RFC 7858. The
security/authentication model has to be completely different. I see
several solutions:

* encoding the key in the auth. server name (as in DNScurve)
* publishing keys in the DNS, secured with DNSSEC (as in DANE), which
  raises an interesting bootstrap problem,
* not checking the keys at all, accepting anything,
* add here your own favorite solution.

Documenting these possible choices would certainly help and we don't
need rechartering to write/read an individual draft :-)

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

Re: [dns-privacy] Stephen Farrell's Yes on draft-ietf-dprive-edns0-padding-02: (with COMMENT)

[Stephane Bortzmeyer]

On Tue, Mar 01, 2016 at 02:07:05AM -0800,
 Stephen Farrell  wrote 
 a message of 43 lines which said:

>[1] http://kpdyer.com/publications/oakland2012-peekaboo.pdf
>[2] http://arxiv.org/pdf/1410.2087v2.pdf

And besides these two papers (I liked the first one, I highly
recommend it), I suggest also:

CLASSIFICATION OF ENCRYPTED WEB TRAFFIC USING MACHINE
LEARNING ALGORITHMS
THESIS
William Charles Barto

http://www.dtic.mil/get-tr-doc/pdf?AD=ADA585816

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

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

[Stephane Bortzmeyer]

On Wed, Mar 16, 2016 at 04:54:33AM +,
 Tirumaleswar Reddy (tireddy)  wrote 
 a message of 64 lines which said:

> This revision addresses comments from Stephane.

Yes, I like the new text in the Security Considerations. But I'm not
completely happy with the changes.

1) There is now no mention of ICMP. I understand why, ICMP is not
authentified but I can hear the IESG asking "What the client should do
when receiving ICMP errors?"

2) You now demultiplex by "Query ID, Query type and Query class". What
about the QNAME? It seems more important than the class...



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

Re: [dns-privacy] Call for agenda for DPRIVE at IETF95 (BA).

[Stephane Bortzmeyer]

On Tue, Mar 15, 2016 at 12:52:00AM +,
 Warren Kumari  wrote 
 a message of 57 lines which said:

> We have some agenda time for DPRIVE in Buenos Aires, please let us
> know is you need some agenda time to present.

I cannot speak for the authors of these drafts but I think
draft-ietf-dprive-dnsodtls and draft-ietf-dprive-dtls-and-tls-profiles
require discussion.

draft-ietf-dprive-dnsodtls for the issues I mentioned in


draft-ietf-dprive-dtls-and-tls-profiles for the "fallback to clear
text" issue raised by Ben Campbell


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

[dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt

[Stephane Bortzmeyer]

On Fri, Jan 22, 2016 at 05:51:22AM +,
 Tirumaleswar Reddy (tireddy)  wrote 
 a message of 62 lines which said:

> This revision addresses comments from Christian and refers to 
> draft-dgr-dprive-dtls-and-tls-profiles.
> Title   : DNS over DTLS (DNSoD)
>   Filename: draft-ietf-dprive-dnsodtls-04.txt

> If the DNS client receives a hard ICMP error [RFC1122], it MUST
> immediately cease attempts to re-transmit its ClientHello.

Isn't there a risk of downgrade attack here? ICMP errors are not
authentified so an active attacker, even if off-path, could convince a
client to disable DNS over DTLS. May be add a reference RFC 5927 to
emphasize that the credibility of ICMP errors should be challenged?
(RFC 5927 is for TCP, I do not find an equivalent for UDP, where the
problem is more complicated, we cannot use the sequence numbers to
check the ICMP message.)

> The existing Query ID allows multiple requests and responses to be
> interleaved in whatever order they can be fulfilled by the DNS
> server.

Only the Query ID? RFC 7766 (a DTLS session, in one way, is a bit like
a TCP connection) says "Since pipelined responses can arrive out of
order, clients MUST match responses to outstanding queries on the same
TCP connection using the Message ID.  If the response contains a
question section, the client MUST match the QNAME, QCLASS, and QTYPE
fields." For DNS over ordinary UDP, I do not find a RFC with clear
rules but RFC 3833 section 2.2 and RFC 5452 section 4 both use more
than the Query ID. Since we are protected by DTLS, we may be more lax
but draft-ietf-dprive-dns-over-tls-04 is not "Since pipelined
responses can arrive out-of-order, clients MUST match responses to
outstanding queries using the ID field, query name, type, and class."

> Implementing DNSoD on root servers is outside the scope of this
> document.

Should be deleted (why only the root servers?)

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

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

[Stephane Bortzmeyer]

On Mon, Jan 04, 2016 at 04:11:18PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 53 lines which said:

>   Filename: draft-ietf-dprive-dns-over-tls-03.txt

A few remarks, nothing to endanger the WG consensus :-)

The draft mentions DNScurve, a resolver-to-auth technique. Because of
the current charter of DPRIVE, I suggest to replace it by DNScrypt


Is it a good idea to keep two profiles in this draft (section 4),
rather than to move everything to
draft-dgr-dprive-dtls-and-tls-profiles?

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

Re: [dns-privacy] DNS PRIVate Exchange

[Stephane Bortzmeyer]

On Fri, Jan 15, 2016 at 11:31:09AM +0500,
 Tariq Saraj  wrote 
 a message of 80 lines which said:

> Unfortunately plaintext is known,

As I said, it is not. You can sometimes *guess* some of the questions
and answers (it is safe to assume that the user's machine will query
google-analytics.com at least from time to time), it does not give you
the full plaintext (query ID, for instance). And, as Shane explained
(you should have read it), modern crypto is not vulnerable to
"known-plaintext attacks".

> I am going to work on it once I complete the confidentiality
> implementation

May I suggest that you learn some crypto first, as well as reading RFC
7626 and the other DPRIVE documents? Check also the implementations
(there are several of DNS-over-TLS, as well as the nonstandard
DNScrypt).



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