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

[Eric Rescorla]

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson  wrote:

>
>
> On 7 Jan 2020, at 22:51, Eric Rescorla  wrote:
>
>
>
> On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson  wrote:
>
>>
>>
>> On 31 Dec 2019, at 14:45, Eric Rescorla  wrote:
>>
>>
>>
> 
>
>
>>
>>> Also on linkability and identification:
>>>
>>> Certain configuration options for encrypted transports could also in
>>> principle fingerprint a user or client application.
>>>
>>>
>>> Though there are definitely ways in which the listed options contribute
>>> to fingerprinting, the paragraph talks about session resumption, where the
>>> concern is primarily linkability.  Mixing these concepts only serves to
>>> confuse rather than enlighten.
>>>
>>> When it comes to fingerprinting, it's important to distinguish between
>>> an ability to identify the software in use (Windows vs. Linux, Safari vs.
>>> Chrome) and the ability to distinguish different users.  The text here
>>> conflates these notions in an unhelpful fashion. The fingerprinting
>>> highlighted is a result of characteristics inherent to the software, not
>>> user-specific details.
>>>
>>>
>>> For the most part, we (as protocol designers) accept that distinguishing
>>> software is possible and we don't generally attempt to erase differences
>>> that only serve to reinforce those signals. Suppressing differences in wire
>>> image across implementations generally runs counter to the desire for
>>> diversity in implementation choices.  This text - perhaps unintentionally -
>>> takes the somewhat sensational position that distinguishing between FreeBSD
>>> and Solaris is as relevant as the sort of fingerprinting that might be used
>>> to isolate individuals.  It does that by concentrating on choices that are
>>> usually made by implementations not individuals.
>>>
>>> This is where a clear recognition of the distinction between
>>> implementation choices and how implementations represent (or maybe don't
>>> represent, if that is the way you feel) the choices of individuals requires
>>> a little more care.  I don't know how easy it is to engage on that topic
>>> without also engaging with the current debate though.
>>>
>>>
>>> Suggest:
>>>
>>> OLD:
>>> “Users of encrypted transports are also highly likely to re-use sessions
>>> for multiple DNS queries to optimize performance (e.g. via DNS pipelining
>>> or HTTPS multiplexing). Certain configuration options for encrypted
>>> transports could also in principle fingerprint a user or client
>>> application.  For example: …."
>>>
>>> NEW:
>>> “Implementations that support encrypted transports are also highly
>>> likely to re-use sessions for multiple DNS queries to optimize performance
>>> (e.g. via DNS pipelining or HTTPS multiplexing). Default configuration
>>> options for encrypted transports could in principle fingerprint a specific
>>> client application. For example:…
>>>
>>
>> I don't generally think that documents like this ought to predict how
>> implementers will behave, so I would remove this text entirely.
>>
>>
>> But one of the points of this document is to describe the actual use of
>> DNS so discussing implementation behaviour seems within scope. Given many
>> of the implementations of DoT are done by DNS developers who might be
>> implementing TLS for the first time highlighting potential privacy
>> considerations with such implementation choices also seems relevant.
>>
>
> There are two problems here:
>
> 1. That you are making predictions about what people will do and that
> those preductions are unsupported by evidence. That needs to go.
>
>
> If you are talking about the specific text above - are you saying you
> don’t believe any existing implementations of encrypted DNS transports
> re-use sessions? If so, I can add the list of ones that do to the document.
> Or you believe they all use the same default configuration options?  If not
> what is the specific prediction you mean?
>

Your text says "highly likely". I'm sure that *some* implementation does,
but that doesn't make it highly likely unless you intend to say "it is
highly likely that some implementation will", which seems silly.


> 2. That you are covering material that is already better covered in 8484,
> so why are you duplicating it?
>
>
> Because this is a general overview of all DNS protocols, RFC8484 is by its
> nature a DoH specific treatise.
>

In that case you ought to just point to the text in 8484 or copy it, not
rewrite it.



>>> Section 3.5.1.2
>>>
>>> I admit that I don't understand the purpose of this section.
>>> Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is
>>> far too low level. If we were to simply assume the usual threat model
>>> [RFC3552], then the conclusions here are obvious: if you fail to
>>> authenticate the server, then you get the server that an attacker chooses.
>>>
>>> I would remove this section in favour of improving Section 3.5.1.4,
>>> which addresses the most pertinent question.
>>>
>>>
>>> RFC7626 included 

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

[Martin Thomson]

On Fri, Jan 10, 2020, at 05:03, Sara Dickinson wrote:
> “As with many other protocols issues around centralisation also arise 
> with DNS. The picture is fluid with several competing factors 
> contributing which can also vary by geographic region. These include:
> * ISP outsourcing, including to third party and public resolvers
> * regional market domination by one or only a few ISPs “
> 
> An increased proportion of the global DNS resolution traffic being 
> served by only a few entities means that the privacy considerations for 
> end users are highly dependant on the privacy policies and practices of 
> those entities.”

This seems fine, but I'd have to see it in context, I think.

> I also previously proposed referencing 
> draft-arkko-iab-internet-consolidation that Stephane mentioned, but Ekr 
> objected. 

That's a poor choice for any citation at this stage.  We're a long way from 
having clearly articulated views on the topic, let alone having any sort of 
consensus.

___
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

[Rob Sayre]

On Thu, Jan 9, 2020 at 10:30 AM Eric Rescorla  wrote:

>
> On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson  wrote:
>
>>
>> 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]
>
> -Ekr
>

I also found this explanation lacking. When the draft states

"the wide practice in HTTP to use various headers to optimize
HTTP connections, functionality and behaviour (which can facilitate user
identification and tracking)"

Which headers is this statement referring to, and which optimizations?


>
>
>>
>> I think the Section 8.2 of RFC8484 states this problem better. Why do we
>> need this section?
>>
>> https://tools.ietf.org/html/rfc8484#section-8.2
>>
>>
>> As others have mentioned - this document gives an overall discussion of
>> privacy across all DNS protocols, RFC8484 is focussed on the DoH specific
>> aspects.
>>
>>
>>
>>
>>> ones with PKI and PGP are clearly out of scope for this document.
>>>
>>
>> I didn't mention PGP--I was talking about misrouting (BGP). I disagree
>> that they are out of scope. Most of the larger TLS use cases rely on PKI..
>>
>>
>> I meant BGP - it was a typo.  Section 2 currently states:
>>
>> “The privacy risks associated with the use of other protocols, e..g.,
>>unencrypted TLS SNI extensions or HTTPS destination IP address
>>fingerprinting are not considered here.”
>>
>
Except the draft does spend a lot of time discussing HTTPS, in a
speculative way that frames the issues as though DoT doesn't have these
problems. It's true that there are two places to put metadata in DoH, but
DoT suffers from all the same risks nevertheless.

It's perfectly possible to add metadata to a DoT request at the TLS layer,
and that data could identify users or clients, just as the draft claims is
the case "if DoH clients commonly include several headers in a DNS message
(e.g., user-agent and accept-language)...".

thanks,
Rob
___
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

[Eric Rescorla]

On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson  wrote:

>
>
> On 7 Jan 2020, at 22:08, Rob Sayre  wrote:
>
> On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson  wrote:
>
>>
>> >
>> > Secondly, I found the entire section "3.5.1.5.2.  DoH Specific
>> Considerations" to be objectionable, and recommend removing it. It mentions
>> many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and
>> contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow
>> extension fields and metadata, so there's nothing unique to DoH here
>> (source: I've implemented DoH and ESNI clients). The entire section amounts
>> to a description of fields that privacy conscious DoH clients /might/ send
>> if they were poorly implemented. But it seems strange to stop there..
>> Implementation quality ratholes can go on for a while: for example, the
>> document doesn't mention the numerous problems with today's TLS, PKI, and
>> BGP infrastructure that apply to both DoT and DoH.
>>
>> As mentioned since this document is an analysis of the privacy
>> considerations of actually _using_ DNS (not just the protocol definitions)
>> then privacy considerations raised by poor implementations seem entirely in
>> scope. The document does also discuss such issues with TLS,
>
>
> The document contains the text:
>
>   "DoT, for example, would normally contain no client identifiers above
>the TLS layer and a resolver would see only a stream of DNS query
>payloads originating within one or more connections from a client IP
>address.  Whereas if DoH clients commonly include several headers in
>a DNS message'
>
> Doesn't this just mean "if the DoT client is a good implementation, and
> the DoH client is not...” ?
>
>
> 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]

-Ekr


>
> I think the Section 8.2 of RFC8484 states this problem better. Why do we
> need this section?
>
> https://tools.ietf.org/html/rfc8484#section-8.2
>
>
> As others have mentioned - this document gives an overall discussion of
> privacy across all DNS protocols, RFC8484 is focussed on the DoH specific
> aspects.
>
>
>
>
>> ones with PKI and PGP are clearly out of scope for this document.
>>
>
> I didn't mention PGP--I was talking about misrouting (BGP). I disagree
> that they are out of scope. Most of the larger TLS use cases rely on PKI.
>
>
> I meant BGP - it was a typo.  Section 2 currently states:
>
> “The privacy risks associated with the use of other protocols, e.g.,
>unencrypted TLS SNI extensions or HTTPS destination IP address
>fingerprinting are not considered here.”
>
> Sara.
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [DNSOP] DNS stamps

[Vladimír Čunát]

On 1/9/20 6:37 PM, Ted Lemon wrote:
> On Jan 9, 2020, at 9:21 AM, Vladimír Čunát  > wrote:
>> Depends what you'd want from the stamps.
> If the stamps make assertions about what service is offered, I’d want
> that to be verifiable.  [...]

I'd personally have stamps without these assertions (or without giving
them any weight).

I see a bigger problem that some of desired assertions are in principle
unverifiable, e.g. "no logging".  Of course, we could (optionally)
extend the string by a signature, but I suspect that'd increase the
length a lot without sufficient gain in exchange.


___
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

[Sara Dickinson]

> On 7 Jan 2020, at 22:51, Eric Rescorla  wrote:
> 
> 
> 
> On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson  > wrote:
> 
> 
>> On 31 Dec 2019, at 14:45, Eric Rescorla > > wrote:
>> 
>> 



>> 
>>> 
>>> Also on linkability and identification:
>>> 
 Certain configuration options for encrypted transports could also in 
 principle fingerprint a user or client application.
>>> 
>>> Though there are definitely ways in which the listed options contribute to 
>>> fingerprinting, the paragraph talks about session resumption, where the 
>>> concern is primarily linkability.  Mixing these concepts only serves to 
>>> confuse rather than enlighten.
>>> 
>>> When it comes to fingerprinting, it's important to distinguish between an 
>>> ability to identify the software in use (Windows vs. Linux, Safari vs. 
>>> Chrome) and the ability to distinguish different users.  The text here 
>>> conflates these notions in an unhelpful fashion. The fingerprinting 
>>> highlighted is a result of characteristics inherent to the software, not 
>>> user-specific details.
>>> 
>>> For the most part, we (as protocol designers) accept that distinguishing 
>>> software is possible and we don't generally attempt to erase differences 
>>> that only serve to reinforce those signals. Suppressing differences in wire 
>>> image across implementations generally runs counter to the desire for 
>>> diversity in implementation choices.  This text - perhaps unintentionally - 
>>> takes the somewhat sensational position that distinguishing between FreeBSD 
>>> and Solaris is as relevant as the sort of fingerprinting that might be used 
>>> to isolate individuals.  It does that by concentrating on choices that are 
>>> usually made by implementations not individuals.
>>> 
>>> This is where a clear recognition of the distinction between implementation 
>>> choices and how implementations represent (or maybe don't represent, if 
>>> that is the way you feel) the choices of individuals requires a little more 
>>> care.  I don't know how easy it is to engage on that topic without also 
>>> engaging with the current debate though.
>> 
>> Suggest:
>> 
>> OLD:
>> “Users of encrypted transports are also highly likely to re-use sessions for 
>> multiple DNS queries to optimize performance (e.g. via DNS pipelining or 
>> HTTPS multiplexing). Certain configuration options for encrypted transports 
>> could also in principle fingerprint a user or client application.  For 
>> example: …."
>> 
>> NEW:
>> “Implementations that support encrypted transports are also highly likely to 
>> re-use sessions for multiple DNS queries to optimize performance (e.g. via 
>> DNS pipelining or HTTPS multiplexing). Default configuration options for 
>> encrypted transports could in principle fingerprint a specific client 
>> application. For example:…
>> 
>> I don't generally think that documents like this ought to predict how 
>> implementers will behave, so I would remove this text entirely.
> 
> But one of the points of this document is to describe the actual use of DNS 
> so discussing implementation behaviour seems within scope. Given many of the 
> implementations of DoT are done by DNS developers who might be implementing 
> TLS for the first time highlighting potential privacy considerations with 
> such implementation choices also seems relevant. 
> 
> There are two problems here:
> 
> 1. That you are making predictions about what people will do and that those 
> preductions are unsupported by evidence. That needs to go.

If you are talking about the specific text above - are you saying you don’t 
believe any existing implementations of encrypted DNS transports re-use 
sessions? If so, I can add the list of ones that do to the document. Or you 
believe they all use the same default configuration options?  If not what is 
the specific prediction you mean? 

> 2. That you are covering material that is already better covered in 8484, so 
> why are you duplicating it?

Because this is a general overview of all DNS protocols, RFC8484 is by its 
nature a DoH specific treatise. 

> 
> 
> 
>> On the surface, this actually seems like quite a good setting for *not* 
>> using TLS session resumption (or TFO, or 0-RTT). Consider a browser, in 
>> which you're likely going to want to connect to the DoH server on startup 
>> and keep that connection open as long as you are doing just about anything 
>> that would cause DNS resolution. You might disconnect when you go really 
>> idle, but then you could get warm again quickly when the user re-engages, at 
>> which point you probably can just accept an extra RT (remember that user 
>> response is quite slow). This isn't something that we have spent a lot of 
>> time optimizing, I don't think, so I suspect there's still a fair bit of 
>> work to do to figure out the best pattern. In any case, making 
>> recommendations here seems premature.
> 
> Where is a recommendation made? I 

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

[Sara Dickinson]

> On 7 Jan 2020, at 22:47, Eric Rescorla  wrote:
> 
> 
> 
> On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson  > wrote:
> 
> 
>> On 19 Dec 2019, at 02:09, Eric Rescorla > > wrote:
>> 
>> 
>> 
>> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson > > wrote:
>> 
>> 
>> > On 2 Dec 2019, at 00:00, Martin Thomson > > > wrote:
> 
> 
> 
>> 
>> Suggest replacing the last 4 paragraphs of this section with the following 
>> text. 
>> 
>> I can't say I like this very much.
>> 
>> “It has been pointed out that should the trend towards using large public 
>> resolvers increase, an increased centralisation of DNS resolution services 
>> will result. 
>> 
>> Well, it's been pointed out, but it's not at all clear that it's true, due 
>> to the large amount of centralization of ISPs in certain areas, so no, I 
>> don't think this document should make this claim.
> 
> To address the more general problem I suggest:
> 
> “Should the trend away from using ISP managed resolvers to using a small set 
> of large public resolvers continue, then an increased proportion of the 
> global DNS resolution traffic will to be served by only a few entities. Some 
> potential impacts of centralisation within the Internet Infrastructure are 
> outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and include 
> some privacy related considerations. "
> 
> 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. I certainly don't agree 
> with citing draft-arkko, which is not at all a neutral or factual source, so 
> this is just a way of incorporating by reference material which doesn't have 
> consensus.

There was much follow up on this point, thank to everyone that contributed. My 
summary of those comments seem to be the there is a desire to include text 
covering the fact that centralisation is happening in many forms and has a 
mixed impact.  I suggest the following text 

“As with many other protocols issues around centralisation also arise with DNS. 
The picture is fluid with several competing factors contributing which can also 
vary by geographic region. These include:
* ISP outsourcing, including to third party and public resolvers
* regional market domination by one or only a few ISPs “

An increased proportion of the global DNS resolution traffic being served by 
only a few entities means that the privacy considerations for end users are 
highly dependant on the privacy policies and practices of those entities.”

I also previously proposed referencing draft-arkko-iab-internet-consolidation 
that Stephane mentioned, but Ekr objected.  

> 
> 
> 
>> An increasing number of applications are offering application-specific 
>> encrypted DNS resolution settings, rather than defaulting to using only the 
>> system resolver. Due to a lack of a standardized discovery mechanism for DoH 
>> and Strict DoT servers, applications that do so are currently limited to 
>> using hard coded lists of resolvers and a variety of heuristics and 
>> resolvers are available in different applications. 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'm not sure what the point of this text is, but it seems kind of 
>> confusing.. In particular, it's not the case that the primary reason that 
>> Firefox uses a hardcoded list is because there is no standardized discovery 
>> mechanism. 
> 
> To clarify I suggest: 
> 
> “An increasing number of applications are offering application-specific 
> encrypted DNS resolution settings, rather than defaulting to using only the 
> system resolver. A variety of heuristics and resolvers are available in 
> different applications including hard-coded lists of recognised DoH/DoT 
> servers.
> 
> 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 don't object to this text, but what's the point?

The point is to describe the privacy considerations of an entirely new 
deployment model for DNS that didn’t exist when the original RFC was published.

> 
> 
>> Everything 

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

[Sara Dickinson]

> On 7 Jan 2020, at 22:08, Rob Sayre  wrote:
> 
> On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson  > wrote:
> 
> > 
> > Secondly, I found the entire section "3.5.1.5.2.  DoH Specific 
> > Considerations" to be objectionable, and recommend removing it. It mentions 
> > many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and 
> > contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow 
> > extension fields and metadata, so there's nothing unique to DoH here 
> > (source: I've implemented DoH and ESNI clients). The entire section amounts 
> > to a description of fields that privacy conscious DoH clients /might/ send 
> > if they were poorly implemented. But it seems strange to stop there.. 
> > Implementation quality ratholes can go on for a while: for example, the 
> > document doesn't mention the numerous problems with today's TLS, PKI, and 
> > BGP infrastructure that apply to both DoT and DoH.
> 
> As mentioned since this document is an analysis of the privacy considerations 
> of actually _using_ DNS (not just the protocol definitions) then privacy 
> considerations raised by poor implementations seem entirely in scope. The 
> document does also discuss such issues with TLS,
> 
> The document contains the text:
> 
>   "DoT, for example, would normally contain no client identifiers above
>the TLS layer and a resolver would see only a stream of DNS query
>payloads originating within one or more connections from a client IP
>address.  Whereas if DoH clients commonly include several headers in
>a DNS message'
> 
> Doesn't this just mean "if the DoT client is a good implementation, and the 
> DoH client is not...” ?

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. 

> 
> I think the Section 8.2 of RFC8484 states this problem better. Why do we need 
> this section?
> 
> https://tools.ietf.org/html/rfc8484#section-8.2 
> 
As others have mentioned - this document gives an overall discussion of privacy 
across all DNS protocols, RFC8484 is focussed on the DoH specific aspects. 

> 
>  
> ones with PKI and PGP are clearly out of scope for this document. 
> 
> I didn't mention PGP--I was talking about misrouting (BGP). I disagree that 
> they are out of scope. Most of the larger TLS use cases rely on PKI.

I meant BGP - it was a typo.  Section 2 currently states:

“The privacy risks associated with the use of other protocols, e.g.,
   unencrypted TLS SNI extensions or HTTPS destination IP address
   fingerprinting are not considered here.”

Sara. 


___
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

[Eric Rescorla]

On Thu, Jan 9, 2020 at 8:49 AM S Moonesamy  wrote:

>
> >That's a very serious misrepresentation of DoH. Counter-example:
> >Google Chrome did DNS resolution with UDP, a long time ago.
>
> I mentioned web browser and not Google Chrome.  I tested a web
> browser which is not Google Chrome.  The DNS queries were sent to the
> local resolver.  I did another test with Firefox.  The DNS queries
> were also sent to the local resolver.
>

I think you're misunderstanding Stephane.

You wrote:
"The choice of resolvers was previously made by the network on which
the user was connected.  Recently, the Internet Engineering Steering
Group approved the standardization of a mechanism so that the choice
can be made by a web browser. "

This isn't correct. Web browsers have *always* been able to choose their
own resolver because DNS is just UDP packets, which the browser is quite
capable of sending (e.g., QUIC, WebRTC). Historically, browsers have
chosen to use the system resolver which customarily gets its choice of
resolver from the network, however, Chrome, at least, for some time has
done DNS resolution itself, albeit using the same resolver as the system
resolver used. However, they could easily have chosen to use 8.8.8.8
(or some other resolver) instead.

The point here is that DoH is orthogonal to the question of which resolver
you use.

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

Re: [dns-privacy] [DNSOP] DNS stamps

[Ted Lemon]

On Jan 9, 2020, at 9:21 AM, Vladimír Čunát  wrote:
> Depends what you'd want from the stamps.

If the stamps make assertions about what service is offered, I’d want that to 
be verifiable.  Otherwise, I can send you a stamp that makes promises I don’t 
intend to keep, and there’s no signature on it, so you have no reason to 
complain when I don’t do what I said I would.   So what’s the point, in that 
case, of making promises?   It’s like the “please respect my privacy” browser 
bit.   Useless.

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

Re: [dns-privacy] [DNSOP] DNS stamps

[Vladimír Čunát]

These stamps do contain interesting ideas, I believe.

On 1/9/20 5:13 PM, Ted Lemon wrote:
> In order for this to actually be useful, two things would be required.
>
> 1. The assertions about resolver behavior (e.g., logging, etc) would
> have to be signed
> [...]

Depends what you'd want from the stamps.  If the main point is to
configure by an URI that's easy to copy, I don't think you really
need these details.  I imagine you'd copy it from an https site of the
operator or got through another trusted (chain of) means.  And I'd
certainly not expect binding such format to some legal mechanisms,
etc... perhaps you could just add policy and some "small print" legalese
to that site as well.

Someone would need to "author" it here.  I don't expect DNSCrypt people
to push it forward within IETF.  I'm not sure what would happen if WG
decides to change the format in an incompatible way, but perhaps that
could be avoided.

BTW, do we want to keep this (whole) thread in *both* mailing-lists at once?

--Vladimir

___
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

[S Moonesamy]

Hi Stephane, Brian,
At 07:44 AM 09-01-2020, Stephane Bortzmeyer wrote:

doh, dnssd and dprive (plus dnsop)?


Yes.


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.


Ok.


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.


It was an actual question.  Thank you for clarifying that it only 
refers to the Answer and other sections.  I also asked about the 
meaning of "is public".  Would it be possible for the working group 
to provide feedback about that?



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.


The Abstract of the draft states that it describes the privacy issues 
associated with the use of the DNS by Internet users.  Section 1 of 
the draft states the use of RFC 1034 and RFC 1035 has many privacy 
implications.  If I understood the above, the draft is only about 
what is in RFC 1034 and RFC 1035 and everything else is out of 
scope.  Is that correct?



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


I mentioned web browser and not Google Chrome.  I tested a web 
browser which is not Google Chrome.  The DNS queries were sent to the 
local resolver.  I did another test with Firefox.  The DNS queries 
were also sent to the local resolver.



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


Ok.

Could the Working Group please see the questions [1] about Section 
3.2 and Section 5?


Regards,
S. Moonesamy

1. 
https://mailarchive.ietf.org/arch/msg/dns-privacy/lS2BdqksRMwKYgg8McnEHEDwhlc 


___
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

[Neil Cook]

> On 9 Jan 2020, at 15:30, Stephane Bortzmeyer  wrote:
> 
> 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?

Well why not switch it the other way round and say that we definitely should 
for SMTP? It’s getting harder and harder to actually get mail delivered if you 
run your own mail server.

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

Re: [dns-privacy] [DNSOP] DNS stamps

[Ted Lemon]

On Jan 9, 2020, at 6:35 AM, Stephane Bortzmeyer  wrote:
> Could be useful specially for secure and public resolvers, may be
> worth of some IETF work?

In order for this to actually be useful, two things would be required.

1. The assertions about resolver behavior (e.g., logging, etc) would have to be 
signed
2. The signature would have to be validatable back to a specific entity that is 
legally competent to make promises
3. There would have to be some legal mechanism, whether actual law or 
precedent, saying that these assertions, when made by competent legal entities, 
constitute a contract.
4. It would have to be possible to automatically determine based on some trust 
model that a particular identity corresponded to an entity that qualified under 
(2)
5. Someone(s) would have to operate (4)

So basically this document does just the easy part, and none of the hard part.  
 And the bulk of the hard part is probably out of scope for the IETF, although 
a model like ACME could work.

I’m not arguing for or against doing this, but let’s be clear about how much 
work it is and what kind of work it is! :)

___
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] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[mohamed.boucadair]

Hi Christian,

Thank you for sharing the pointer.

As I understood it, the aggregation mentioned in Pawel and Oliver's study is 
based on an “AS name”, not AS numbers. As you know, an organization may own 
multiple ASNs. Mapping the 22/57 ASes to their owner would be useful, IMO.

Cheers,
Med

De : dns-privacy [mailto:dns-privacy-boun...@ietf.org] De la part de Christian 
Huitema
Envoyé : jeudi 9 janvier 2020 09:28
À : BOUCADAIR Mohamed TGI/OLN; Vittorio Bertola; Sara Dickinson
Cc : last-c...@ietf.org; DNS Privacy Working Group
Objet : Re: [dns-privacy] [Last-Call] Review of 
draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments



On 1/8/2020 6:09 AM, 
mohamed.boucad...@orange.com wrote:
FWIW, slide 6 of 
https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01
 shows that very few DNS providers are handling +53% of the traffic. It is fair 
to mention the risk to see such centralization further exacerbated. Of course, 
the one mentioned by Christian is to be called as well

I am not sure that I understand the methodology behind the slides that you 
cite, but it appears that they are measuring traffic by volume based on passive 
DNS data collection.

I have been working with the APNIC data, as published at 
https://ithi.research.icann.org/graph-m5.html. The data attempts to answer the 
question, how many "resolvers" handle what fraction of the user population. The 
first problem is "how do you identify resolvers". The classic simplification is 
to just count autonomous system numbers (AS), but this lumps together the 
resolvers managed by ISP and those managed by small businesses connecting 
through those ISP. The immediate problem is, "how do you count", because users 
and their devices sometimes send multiple copies of the same query to different 
resolvers, and also sometimes send a second batch of queries to a different set 
of resolvers if they did not get a response the first time. One way to count 
would be, all the resolvers needed to handle all the repetitions of the queries 
of a users. Let's call that the inclusive count. Another way would be, the 
smallest numbers of resolvers that would handle X% of the users, if all the 
other resolvers were out of service. Let's call that the exclusive count, which 
is by definition smaller than the inclusive count.

As of January 2020, the data shows that:
 * The traffic of 50% of the users is seen by resolvers in 57 AS (inclusive 
count). Handling that traffic would require at least 22 AS (exclusive count).
 * The traffic of 90% of the users is seen by resolvers in 570 AS 
(inclusive count). Handling that traffic would require at least 385 AS 
(exclusive count).

If we count by network prefix (/24 for IPv4, /48 for IPv6), we get:
 * The traffic of 50% of the users is seen by resolvers in 478 networks 
(inclusive count). Handling that traffic would require at least 143 networks 
(exclusive count).
 * The traffic of 90% of the users is seen by resolvers in 3403 networks 
(inclusive count). Handling that traffic would require at least 2150 networks 
(exclusive count).

Is that a form of concentration? Yes of course, but even the lowest number, 22 
AS, is larger than the 8 networks mentioned as handling 53% of traffic in Pawel 
and Oliver's study.

And yes, it is important to monitor these trends.

-- Christian Huitema




___
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

[Christian Huitema]

On 1/8/2020 6:09 AM, mohamed.boucad...@orange.com wrote:
> FWIW, slide 6 of
> https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01
> shows that very few DNS providers are handling +53% of the traffic. It
> is fair to mention the risk to see such centralization further
> exacerbated. Of course, the one mentioned by Christian is to be called
> as well

I am not sure that I understand the methodology behind the slides that
you cite, but it appears that they are measuring traffic by volume based
on passive DNS data collection.

I have been working with the APNIC data, as published at
https://ithi.research.icann.org/graph-m5.html. The data attempts to
answer the question, how many "resolvers" handle what fraction of the
user population. The first problem is "how do you identify resolvers".
The classic simplification is to just count autonomous system numbers
(AS), but this lumps together the resolvers managed by ISP and those
managed by small businesses connecting through those ISP. The immediate
problem is, "how do you count", because users and their devices
sometimes send multiple copies of the same query to different resolvers,
and also sometimes send a second batch of queries to a different set of
resolvers if they did not get a response the first time. One way to
count would be, all the resolvers needed to handle all the repetitions
of the queries of a users. Let's call that the inclusive count. Another
way would be, the smallest numbers of resolvers that would handle X% of
the users, if all the other resolvers were out of service. Let's call
that the exclusive count, which is by definition smaller than the
inclusive count.

As of January 2020, the data shows that:
 * The traffic of 50% of the users is seen by resolvers in 57 AS
(inclusive count). Handling that traffic would require at least 22 AS
(exclusive count).
 * The traffic of 90% of the users is seen by resolvers in 570 AS
(inclusive count). Handling that traffic would require at least 385 AS
(exclusive count).

If we count by network prefix (/24 for IPv4, /48 for IPv6), we get:
 * The traffic of 50% of the users is seen by resolvers in 478
networks (inclusive count). Handling that traffic would require at least
143 networks (exclusive count).
 * The traffic of 90% of the users is seen by resolvers in 3403
networks (inclusive count). Handling that traffic would require at least
2150 networks (exclusive count).

Is that a form of concentration? Yes of course, but even the lowest
number, 22 AS, is larger than the 8 networks mentioned as handling 53%
of traffic in Pawel and Oliver's study.

And yes, it is important to monitor these trends.

-- Christian Huitema



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

[dns-privacy] FW: New Version Notification for draft-reddy-dprive-bootstrap-dns-server-06.txt

[Konda, Tirumaleswar Reddy]

This revision 
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-06 
addresses comments from the WG. Section 2 is updated to discuss scope and use 
cases.

As a reminder, the specification discusses

(1) Bootstrapping phase to securely bootstrap endpoint devices with the 
authentication domain name (ADN) and DNS server certificate of the local 
network's DNS server.
(2) Discovery phase to discover the privacy-enabling protocols supported by the 
local DNS server.
(3) Connection handshake and DNS server certificate validation.

Comments and suggestions are more than welcome.

Cheers,
-Tiru

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Thu, 9 Jan 2020 at 13:38
Subject: New Version Notification for 
draft-reddy-dprive-bootstrap-dns-server-06.txt
To: Mohamed Boucadair 
mailto:mohamed.boucad...@orange.com>>, Dan Wing 
mailto:dwing-i...@fuggles.com>>, Michael C. Richardson 
mailto:mcr%2bi...@sandelman.ca>>, Tirumaleswar Reddy.K 
mailto:kond...@gmail.com>>



A new version of I-D, draft-reddy-dprive-bootstrap-dns-server-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-dprive-bootstrap-dns-server
Revision:   06
Title:  A Bootstrapping Procedure to Discover and Authenticate 
DNS-over-(D)TLS and DNS-over-HTTPS Servers
Document date:  2020-01-09
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-reddy-dprive-bootstrap-dns-server-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-reddy-dprive-bootstrap-dns-server/
Htmlized:   
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-06
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-reddy-dprive-bootstrap-dns-server
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-reddy-dprive-bootstrap-dns-server-06

Abstract:
   This document specifies mechanisms to automatically bootstrap
   endpoints (e.g., hosts, Customer Equipment) to discover and
   authenticate DNS-over-(D)TLS and DNS-over-HTTPS servers provided by a
   local network.




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

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