[DNSOP] BCP 222, RFC 8553 on DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.

BCP 222
RFC 8553

Title:  DNS Attrleaf Changes: Fixing Specifications 
That Use Underscored Node Names 
Author: D. Crocker
Status: Best Current Practice
Stream: IETF
Date:   March 2019
Mailbox:dcroc...@bbiw.net
Pages:  15
Characters: 33458
Updates:RFC 2782, RFC 3263, RFC 3529, RFC 3620, 
RFC 3832, RFC 3887, RFC 3958, RFC 4120, 
RFC 4227, RFC 4386, RFC 4387, RFC 4976, 
RFC 5026, RFC 5328, RFC 5389, RFC 5415, 
RFC 5518, RFC , RFC 5617, RFC 5679, 
RFC 5766, RFC 5780, RFC 5804, RFC 5864, 
RFC 5928, RFC 6120, RFC 6186, RFC 6376,
RFC 6733, RFC 6763, RFC 7208, RFC 7489, 
RFC 8145
See Also:   BCP 222

I-D Tag:draft-ietf-dnsop-attrleaf-fix-07.txt

URL:https://www.rfc-editor.org/info/rfc8553

DOI:10.17487/RFC8553

Using an underscore for a prefix creates a space for constrained
interoperation of resource records.  Original uses of an underscore
character as a domain node name prefix were specified without the
benefit of an IANA registry.  This produced an entirely uncoordinated
set of name-creation activities, all drawing from the same namespace.
A registry for these names has now been defined by RFC 8552.
However, the existing specifications that use underscored naming need
to be modified in order to be in line with the new registry.  This
document specifies those changes.  The changes preserve existing
software and operational practice, while adapting the specifications
for those practices to the newer underscore registry model.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] BCP 222, RFC 8552 on Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.

BCP 222
RFC 8552

Title:  Scoped Interpretation of DNS Resource Records 
through "Underscored" Naming of Attribute Leaves 
Author: D. Crocker
Status: Best Current Practice
Stream: IETF
Date:   March 2019
Mailbox:dcroc...@bbiw.net
Pages:  15
Characters: 35306
See Also:   BCP 222

I-D Tag:draft-ietf-dnsop-attrleaf-16.txt

URL:https://www.rfc-editor.org/info/rfc8552

DOI:10.17487/RFC8552

Formally, any DNS Resource Record (RR) may occur under any domain
name.  However, some services use an operational convention for
defining specific interpretations of an RRset by locating the records
in a DNS branch under the parent domain to which the RRset actually
applies.  The top of this subordinate branch is defined by a naming
convention that uses a reserved node name, which begins with the
underscore character (e.g., "_name").  The underscored naming
construct defines a semantic scope for DNS record types that are
associated with the parent domain above the underscored branch.  This
specification explores the nature of this DNS usage and defines the
"Underscored and Globally Scoped DNS Node Names" registry with IANA.
The purpose of this registry is to avoid collisions resulting from
the use of the same underscored name for different services.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Vittorio Bertola]

> Il 20 marzo 2019 alle 12.38 Joe Abley  ha scritto:
> 
> Seems to me that there's a middle ground within sight here.
> 
> Standardise this privacy mechanism, and specify (with reasoning) that it 
> should be implemented such that the existence of the channel (but not the 
> content) can be identified as distinct from other traffic by third parties. 
> Maybe specify use of a different port number, as was done with DoT.
> 
> Those who choose to ignore that direction and create a covert channel using 
> port 443 instead will do so. Nothing much we can do to stop that today (I 
> guarantee it is already happening). The future is not really different.

This is actually the recommendation in section 4.6 of my draft :-) And I agree, 
it looks like the only possible and reasonable compromise between the two 
viewpoints.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Matthew Pounsett]

On Wed, 20 Mar 2019 at 07:38, Joe Abley  wrote:

> [There is actually a proposal at the bottom of this e-mail. Bear with me.]
>

And it's a good proposal!


>
> Standardise this privacy mechanism, and specify (with reasoning) that it
> should be implemented such that the existence of the channel (but not the
> content) can be identified as distinct from other traffic by third parties.
> Maybe specify use of a different port number, as was done with DoT.
>

I think this would alleviate most people's concerns... certainly it deals
wth mine.  I have difficulty believing it is acceptable to pro-DoH
community though, considering the first of the two use-cases defined in the
Introduction of RFC8484: "... preventing on-path devices from interfering
with DNS operations..."

I eagerly welcome the -bis document that removes this statement, and
defines a new port number which DoH traffic SHOULD use.

Those who choose to ignore that direction and create a covert channel using
> port 443 instead will do so. Nothing much we can do to stop that today (I
> guarantee it is already happening). The future is not really different.
>

Indeed.  If everyone above-board is using port 5443 (to pull a number out
of the air) for their DoH traffic, the below-board usage should be about as
visible as any such usage is today.

Of course when people shift the focus of the conversation from DoH in
> general to resolverless DNS, and want to interleave DNS messages with HTML
> and cat GIFs over the same HTTPS bundles, the pitchforks will need to come
> out again. So keep them handy.
>

I don't actually own a pitchfork, but I'll keep my Woodsman's Pal sharp. :)

>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Jared Mauch]

It’s also about DLP and other related topics. There is a deep well here we keep 
tiptoeing around. Some things are mitigated by enterprise certificates and 
others are far more tricky. 

Doing this with DNS helps with that defense in depth. Removing that layer of 
defense will increase risks on one side while decreasing them on the other. 

You also have a hard time telling employees why you have a MITM box and it 
reduces your talent pool. 

People here may not worry about it but the insurance carriers for the 
businesses do. 

Sent from my iCar

> On Mar 20, 2019, at 4:08 PM, Matthew Pounsett  wrote:
> 
> I can't afford to probe every IP address on the planet on a regular basis, 
> and dynamically modify my blocking based on that.  It's far, far less 
> expensive to just automatically MitM all web traffic on my network, even 
> though that is far more expensive than what I have to do today.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Matthew Pounsett]

On Tue, 19 Mar 2019 at 13:45, Ted Hardie  wrote:

>
>> I have a relationship with my users and I can control the configuration
>> of their *known* applications.  I do not have a relationship with the
>> malware author that is trying to steal their data, and cannot control the
>> configuration of that (unknown) application.  By running DoT on my borders
>> and blocking all other DNS and DoT traffic, I can provide privacy for my
>> users while still preventing malware from doing its thing.
>>
>
> As I said to Paul, I don't think you can if your only defense is blocking
> DNS access.  Coding a system to use a non-standard resolution protocol over
> TLS is relatively easy; all the malware needs is a specific target to start
> at.  That target can be hard coded, derived from the output of a web
> search, or produced by the output of an algorithm resident in the malware
> and some system-available data (commonly the time).  My apologies if I have
> misunderstood your point here, but unless you also block all traffic for
> which you have seen no resolution event, I believe that it is entirely
> possible to circumvent the defense you describe.
>

I think you need to understand a bit of the history of malware development
and the arms race to block it.

Malware C started out at hard-coded IP addresses.  They quickly realized
this didn't work because going to a single address for your C is easily
spotted, easily filtered, and easily taken down.  So they moved to using
domain names and DNS; they could change the IP addresses that their C
domains resolved to very quickly, and move C around, avoiding takedown.
After a while, the domain sales business got better at domain takedowns,
and so malware developers moved from single domains to DGAs.  Which is
where we are today.

Using a hard-coded endpoint for domain resolution, even if it's TLS
encrypted, is as easily spotted and dealt with as using a single hard-coded
endpoint for C it can be filtered as soon as the anomaly is detected.
Using DGAs to bootstrap such hidden resolution systems has the same
limitations as DGAs above.  It's just adding an extra layer of abstraction,
using identical systems, over the C in the first place.  The fact that
they are NOT doing this today, even in the face of domain reputation
systems and RPZ feeds should tell you something.  I'd bet any malware
author who's though of doing what you suggest got at most a few dozen lines
into writing the code, realized they were just reimplementing their
existing C, and stopped.


>
>
>> With DoH available at endpoints that my users want to reach using some
>> other application,
>>
>
> And this is the critique that is not of DoH as a protocol, but of a
> specific deployment possibility.  You've seen the Quad9 folks point and the
> Chrome statement of their current deployment plans.  The first said they
> will not deploy DNS resources and other web resources on commingled hosts.
> The second said that they will only use DoH after a probe reveals that it
> is available *at the already configured DNS service*.  This is entirely in
> line with Section 3 of RFC 8484:
>

Quad9 and Chrome's current policies are no guarantee of their future
policies, nor the policies of other major browser developers or web
properties.  I cannot assume a statement made by either organization is
binding on the entire Internet.

When have you ever seen the Internet writ large choose NOT to do a thing
that was enabled by the technology?  The protocol enables (and even
encourages) the deployment possibility, so why shouldn't I expect it?  As
soon as DoH the protocol is in GA codebase of major web browsers there will
immediately be enough uptake on DoH server operation to enable the thing
operators are concerned about.  And remember, the protocol is DESIGNED to
inhibit interference by hiding resolution streams along side other, less
easily blocked traffic.  You seem to be making the argument here, "don't
worry, you'll still be able to interfere with DoH resolution by clients you
don't control."  If so, that is disingenuous at best.

>A DoH client MUST NOT use a different URI simply because it was
>discovered outside of the client's configuration (such as through
>HTTP/2 server push) or because a server offers an unsolicited
>response that appears to be a valid answer to a DNS query.  This
>specification does not extend DNS resolution privileges to URIs that
>are not recognized by the DoH client as configured URIs.
>
>
> Browsers do not have an incentive to permit random websites to poison
> their caches, so I strongly suspect that there will be no ability to pass a
> resolution done in JavaScript down into the browser cache; my experience
> during RTCWeb was that the browsers treated all downloaded JavaScript
> applications as potentially malign.
>

As I (and others) have stated several times, browsers aren't the ultimate
problem.  They will be configurable and thus controllable, when they're
cooperative.  

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Matthew Pounsett]

On Tue, 19 Mar 2019 at 13:37, Christian Huitema  wrote:

>
> On 3/19/2019 12:50 AM, Eliot Lear wrote:
>
> On 19 Mar 2019, at 01:50, Matthew Pounsett  wrote:
>
> Somewhere up-thread it was suggested that there are other reasonable steps
> that a network/security operator can take to maintain the controls over
> resolution that we have today, but so far I haven't seen them enumerated
> anywhere.
>
>
> I had stated that one can use an MDM to manage the endpoint’s use of DoH.
> This doesn’t eliminate the possibility of malware, but does reduce
> misconfiguration in the enterprise, and provides for some protection
> against infection by blocking known bad names.
>
> Configuration works well for functions like "phishing protection": the
> device users in most cases want some form of protection, and then it is a
> matter of how this protection is configured. It does not work so well for
> functions like intrusion detection, such as figuring out whether a device
> is trying to contact a botnet C, because we cannot expect the infected
> device to be amenable to configuration.
>
Yes.  I'm not particularly concerned about cooperative clients.  Even if
it's not possible today, the economics of large enterprises will force
browsers et. al. to make their software configurable in some automated,
mass-update way that works for 50k+ employee companies.  I'll be able to
use the same controls to force cooperative clients to use my resolver,
whether that be DoT or DoH.

It's the uncooperative clients that I'm concerned about, and the presence
of DoH endpoints at the same IP:port pair as other web sites means that in
order to deal with uncooperative clients, operators will have to
block/proxy all external port 443 traffic in order to make sure malware
can't get access to resolution they don't control.

In addition, there’s at least a heuristic for detection: compare data plane
> activity against ANSWERs.  If you’re seeing activity to addresses that
> don’t match (modulo some noise), you know an alternate resolver is active
> on that device.  And while it’s possible for malware to mimic queries to
> Do53 for Good sites versus what it really wants to access, you start
> tarnishing the rep of the IP address as and when you detect the problem
> through other means (AV s/w, honey pots, binary inspection, et al).  That
> leaves it with cloud providers to sort their wagons.
>
> Yes, one could imagine IP address or IP prefix reputation systems, similar
> to the IP address block lists used to protect against spam. This would
> work, and it would also provide intrusion detection signals when an
> infected device starts contacting a botnet. The problem of course is the
> gray line between "blocking phishing sites" and "blocking content that I
> disagree with". The various attempts to block the whole of Wikipedia in
> order to block some specific pages shows where this can lead.
>
The distinction between blocking single pages vs. blocking whole domains
isn't really relevant here since we're talking about DNS-based blocking in
the first place.  However, there's a similar problem between blocking
domain resolution and blocking the IP address a domain resolves to.  Right
now operators can block access to malwareCnC.com even if it resides on the
same web server as useful.website.net because of the way virtual hosting
works.  If operators have to replace their domain reputation feeds with
address reputation feeds there's going to be less fine-grained control and
collateral damage.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Jacques Latour]

It's not what you access, it's what you block, since reverse DNS is not a good 
solution in this instance, you need to map the DNS block list to it's IP 
addresses and block those IPs, and readjust based on TTL, you'll end up 
blocking more stuff than intended, huge mess, but if you can't trust the DNS to 
be clean then that's one option to enforce a security policy when browsers are 
using DoH. This should probably go in 
draft-livingood-doh-implementation-risks-issues

Jacques

>-Original Message-
>From: Adam Roach 
>Sent: March 20, 2019 2:15 PM
>To: Jacques Latour ; Jared Mauch
>; Brian Dickson 
>Cc: Ted Hardie ; DoH WG ; dnsop
>; paul vixie ; Michael Sinatra
>; Stephen Farrell 
>Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
>
>On 3/20/19 12:59 PM, Jacques Latour wrote:
>> I'm trying to balance in my mind the requirements to protect the DNS
>> vs. what is happening on the wire, in the end, the browser will
>> connect to an IP address which can be (in most case) mapped to a
>> domain name
>
>
>I don't think this second assertion is true in 2019. See if you can make even a
>first-order reasonable guess what I'm accessing at 172.217.1.129 or
>23.227.38.32 or 52.40.19.98 or 216.105.38.15 or 104.20.1.85.
>
>(Hint: I took these all from sites I visit frequently, and none are 
>particularly
>obscure sites)
>
>/a

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[神明達哉]

At Wed, 20 Mar 2019 12:38:05 +0100,
Joe Abley  wrote:

> > Often as an industry we may discuss various solutions that are great
for oneself but don’t scale when looking at the big picture.
>
> I think what we are seeing is the fundamental tension between privacy and
control. You need to give up some privacy in order to make the control
possible; you need to give up some control in order to afford privacy.

> Some in this thread want certainty that they are able to exercise
control, e.g. for devices in their network.

> Some in this thread want certainty that they can obtain privacy, e.g. for
for their device in any network.

[...]

Thank you for the nice, concise summary.  I think it's well-balanced
observation of where we are.  (I'm so glad I can finally see a
constructive post after seeing a common pattern of boring IETF
discussion, where people with different opinions just keep stating
their views without making any real progress:).

> Seems to me that there's a middle ground within sight here.
>
> Standardise this privacy mechanism, and specify (with reasoning) that it
should be implemented such that the existence of the channel (but not the
content) can be identified as distinct from other traffic by third parties.
Maybe specify use of a different port number, as was done with DoT.

I see that those who want to exercise control can live with this (or
at least using a different set of IP addresses for DoH servers than
those for other ordinary web services).  But I'm not so sure if that's
acceptable for the other group.  In that sense I'm curious whether
some big possible DoH providers are now willing to accept this middle
ground.  If my memory is correct the longer term plan at Google (and
maybe also Clouldflare?) is to provide DoH service on the same IP
addresses as those for other ordinary and popular web services (and on
port 443, of course), so that an intermediate operator cannot easily
block access to their DoH services.

> Those who choose to ignore that direction and create a covert channel
using port 443 instead will do so. Nothing much we can do to stop that
today (I guarantee it is already happening). The future is not really
different.

True.  But I think giant providers tend to respect a community
consensus.  Niche or really malicious players may/will still ignore
it, but it would be very difficult for them to collocate their DoH
services with other important web services that can hardly be blocked,
so it shouldn't be a big problem for "those who want certainty of
control".  So if we can really agree on the above "middle ground" and
publish a BCP or something that describes the consensus, I guess we
can now really work on technical issues.  But I'm not sure if we can
reach that consensus.

--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Adam Roach]

On 3/20/19 12:59 PM, Jacques Latour wrote:

I'm trying to balance in my mind the requirements to protect the DNS vs. what 
is happening on the wire, in the end, the browser will connect to an IP address 
which can be (in most case) mapped to a domain name



I don't think this second assertion is true in 2019. See if you can make 
even a first-order reasonable guess what I'm accessing at 172.217.1.129 
or 23.227.38.32 or 52.40.19.98 or 216.105.38.15 or 104.20.1.85.


(Hint: I took these all from sites I visit frequently, and none are 
particularly obscure sites)


/a

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Jacques Latour]

I'm trying to balance in my mind the requirements to protect the DNS vs. what 
is happening on the wire, in the end, the browser will connect to an IP address 
which can be (in most case) mapped to a domain name, which we're trying to 
protect/hide with all sorts of encryption.  Someone that has access to the DNS 
on the wire can see what is queried, someone with wire access can see who is 
connecting where.  Where's the privacy protected here? Do we need to balance 
both?

DoH is going to force enterprises/network operator to beef up their security 
policies by enforcing higher level of outbound IP address filtering. Having a 
matching DNS block list in corresponding outbound IP address filters. Going to 
be messy :-)

Jacques

 

>-Original Message-
>From: DNSOP  On Behalf Of Jared Mauch
>Sent: March 20, 2019 6:10 AM
>To: Brian Dickson 
>Cc: Ted Hardie ; DoH WG ; dnsop
>; paul vixie ; Michael Sinatra
>; Stephen Farrell 
>Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
>
>
>
>> On Mar 19, 2019, at 11:17 PM, Brian Dickson
> wrote:
>>
>>
>>
>> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell 
>wrote:
>>
>> Hiya,
>>
>> One individualistic data point on this sub-topic, and a real point:
>>
>> On 20/03/2019 01:13, Jared Mauch wrote:
>> > My impression is there are people who will not be satisfied until
>> > all traffic looks identical and you have zero way to protect your
>> > home,
>>
>> I do not claim that everyone ought do the same, but I absolutely do
>> claim that encouraging voluntary policy adherence by dealing with the
>> people using the n/w is preferable to many egregiously invasive
>> attempts to force technical policy enforcement on unwilling serf-like
>> users.
>>
>> So, this is the problem:
>> - If a network operator has any policy that is enforceable, ONLY the 
>> technical
>policy enforcement model scales.
>> - In such an environment, there are only, ever, "willing users", because, in
>order to use the network, they are required to agree to the policies.
>>
>> This makes the argument you have above, a vacuously defined one.
>> You want to encourage voluntary policy adherence for a non-existent set of
>otherwise unwilling users.
>>
>> I understand your position: you would prefer that {some,all} networks were
>not employing policies that {you,some people} disagree with.
>> I sympathize, but I disagree. What we need are mechanisms that scale.
>> My position (personally) is that we find ways to have scalable, technical
>mechanisms.
>> They should allow users (or machine administrators) to be as compliant as
>they are willing, and no more.
>> They should allow networks to enforce their policies, while treading as 
>> lightly
>as possible.
>> It should be possible to use technical means to handle this negotiation with
>little to no user input required.
>> The analogy is roughly that of escalation-of-force in law enforcement, 
>> starting
>at a level of "polite requests".
>>
>> You can disagree, but I implore you: please don't stand in the way of those
>wanting to find consensus on scalable, flexible, technical solutions that
>encompass a wide range of network policies and enforcement needs.
>>
>> The main point is, I believe the end result will be mechanisms that allow you
>to deploy networks that meet your needs, and software that you can configure
>to bypass such controls, but that neither of those should ever be the default
>configurations.
>>
>> If the results allow you to do what you want/need, and also allow others to 
>> do
>what they want/need, everyone should be happy enough with the result.
>>
>> Can we at least agree on this as a desired goal for this work?
>
>Often as an industry we may discuss various solutions that are great for 
>oneself
>but don’t scale when looking at the big picture.  I’m of the feeling that not
>everything should be a standard, even things that look like they might be
>standard-ish.  I could encode many things over TCP over TLS over QUIC over
>HTTP.  I’ve seen unencoded data stored in DNS TXT records that have
>sorted/ordered information so you can do interesting things.
>
>Just because one can do these things doesn’t mean one should, or that the
>entirety of the industry should (or even will).
>
>Goals and motivations are key here, if the goal is to make it such that 
>dissidents
>whose lives may be threatened (this is an example a co-worker always uses on
>me in these types of conversations to support their position) by the local 
>regime
>may face a threatening situation or die as a result of using technology, it’s 
>not
>the fault of the protocol.  Should we improve for every corner case like this? 
> As
>vixie has pointed it, it may be an innocuous device like a chromecast where the
>ISP provided DNS is horrible.  (I can think of many bad devices in the consumer
>space that break the DNS spec in really unique ways).  It’s entirely possible 
>that
>the appliance works best when not using that ISP service, but it is also data
>leakage to a 

[DNSOP] Rough Agenda for IETF104

[Tim Wicinski]

All

I've put together a rough agenda from our agenda requests and uploaded
into the data tracker:

https://datatracker.ietf.org/meeting/104/materials/agenda-104-dnsop-00

I've probably missed something in our email, but don't blame the other
chairs for anything.   I will be in Prague Thursday evening and will be
banging on this over the next 24-48 hours.

Thanks
Tim

---
# DNS Operations (DNSOP) Working Group
## IETF 104

## Session I

* Date: 26 March 2019
* Time: 13:50-15:50 CET (12:50-14:50 UTC)
* Room:  Congress Hall 1

* Chairs: Tim Wicinski 
* Chairs: Suzanne Woolf 
* Chairs: Benno Overeinder 

* IESG Overlord: Warren Kumari 

* [Document Status](
https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.txt)
* [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/)

---
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

* Updates of Old Work, Chairs, 10 min

---
### Current Working Group Business


* Draft name: draft-ietf-dnsop-multi-provider-dnssec-00
  URL:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/
  Requester Email: Shumon Huque 

* Draft name: draft-wessels-dns-zone-digest-06  (If Needed)
  datatracker URL:
https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
  Requester Email: dwess...@verisign.com

* Draft name: raft-ietf-dnsop-dns-tcp-requirements-03
  datatracker URL:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/
  Requester Email: dwess...@verisign.com

* Draft name: draft-livingood-dnsop-dont-switch-resolvers
  datatracker URL:
https://datatracker.ietf.org/doc/draft-livingood-dnsop-dont-switch-resolvers/
  Requester Email: Jason Livingood 

* Draft name: draft-livingood-dnsop-auth-dnssec-mistakes
  datatracker URL:
https://datatracker.ietf.org/doc/draft-livingood-dnsop-auth-dnssec-mistakes/
  Requester Email: Jason Livingood 

* Draft name: draft-lhotka-dnsop-iana-class-type-yang
  datatracker URL:
https://datatracker.ietf.org/doc/draft-lhotka-dnsop-iana-class-type-yang/
  Requester Email: Ladislav Lhotka 

---
### New Working Group Business

* Draft name: draft-moura-dnsop-authoritative-recommendations
  datatracker URL:
https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/
  Requester Email: giovane.mo...@sidn.nl

* Draft name: draft-sury-toorop-dns-cookies-algorithms
(draft-sury-rfc7873bis)
  datatracker URL:
https://datatracker.ietf.org/doc/draft-sury-toorop-dns-cookies-algorithms/
  Requester Email: Ondrej Sury 


* Draft name: draft-stw-6761ext
  datatracker URL: https://datatracker.ietf.org/doc/draft-stw-6761ext/
  Requester Email: Suzanne Woolf 

---
### Time Permitting


## Session II

* Date: 29 March 2019
* Time: 09:30-10:30 CET (08:30-09:30 UTC)
* Room:  Congress Hall 2

* Chairs: Tim Wicinski 
* Chairs: Suzanne Woolf 
* Charis: Benno Overeinder 

* IESG Overlord: Warren Kumari 

* [Document Status](
https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.txt)
* [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/)

---
## Agenda
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] dnsop meeting agenda?

[Tim Wicinski]

Hi

I've been trying to push out a version but has been tied up in all day work
meetings this week with poor internet sadly.
We should have one up today.

Tim


On Wed, Mar 20, 2019 at 10:32 AM 神明達哉  wrote:

> There's still no link to meeting agenda of dnsop sessions on the
> IETF104 agenda page: https://datatracker.ietf.org/meeting/104/agenda/
>
> Is it some kind of operation error or is the agenda still unavailable?
> If it's the latter, when can we expect to see it?
>
> --
> JINMEI, Tatuya
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] dnsop meeting agenda?

[神明達哉]

There's still no link to meeting agenda of dnsop sessions on the
IETF104 agenda page: https://datatracker.ietf.org/meeting/104/agenda/

Is it some kind of operation error or is the agenda still unavailable?
If it's the latter, when can we expect to see it?

--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Joe Abley]

[There is actually a proposal at the bottom of this e-mail. Bear with me.]

On 20 Mar 2019, at 11:09, Jared Mauch  wrote:

> Often as an industry we may discuss various solutions that are great for 
> oneself but don’t scale when looking at the big picture.

I think what we are seeing is the fundamental tension between privacy and 
control. You need to give up some privacy in order to make the control 
possible; you need to give up some control in order to afford privacy.

Some in this thread want certainty that they are able to exercise control, e.g. 
for devices in their network.

Some in this thread want certainty that they can obtain privacy, e.g. for for 
their device in any network.

When those people meet, the pitchforks come out. This is already true today; 
it's not a new DoH problem. I think the balance of the tensions has shifted 
with the prospect of a change in default behaviour, not because any of this is 
fundamentally new. The change in defaults tips the power balance (e.g. the 
balance of cost) between control and privacy. This is Paul's basic point, I 
think.

Some people seem to be getting worked up about whether the desire for control 
is more important than the desire for privacy. I don't think that question has 
an answer, but I think most reasonable people could acknowledge that both 
positions exist. This is Stephen's basic point, I think.

It's possible today to communicate over covert channels in order to avoid 
control. This is different from *all* communication happening over covert 
channels so that no control in the future is possible. That's not how things 
happen today; that would be a change, a new situation. This is your basic 
point, I think (that's how I read "scale" in your e-mail, above).

Seems to me that there's a middle ground within sight here.

Standardise this privacy mechanism, and specify (with reasoning) that it should 
be implemented such that the existence of the channel (but not the content) can 
be identified as distinct from other traffic by third parties. Maybe specify 
use of a different port number, as was done with DoT.

Those who choose to ignore that direction and create a covert channel using 
port 443 instead will do so. Nothing much we can do to stop that today (I 
guarantee it is already happening). The future is not really different.

Of course when people shift the focus of the conversation from DoH in general 
to resolverless DNS, and want to interleave DNS messages with HTML and cat GIFs 
over the same HTTPS bundles, the pitchforks will need to come out again. So 
keep them handy.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Jared Mauch]

> On Mar 19, 2019, at 11:17 PM, Brian Dickson  
> wrote:
> 
> 
> 
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell  
> wrote:
> 
> Hiya,
> 
> One individualistic data point on this sub-topic, and a real point:
> 
> On 20/03/2019 01:13, Jared Mauch wrote:
> > My impression is there are people who will not be satisfied until all 
> > traffic looks
> > identical and you have zero way to protect your home,
> 
> I do not claim that everyone ought do the same, but I absolutely
> do claim that encouraging voluntary policy adherence by dealing
> with the people using the n/w is preferable to many egregiously
> invasive attempts to force technical policy enforcement on
> unwilling serf-like users.
> 
> So, this is the problem:
> - If a network operator has any policy that is enforceable, ONLY the 
> technical policy enforcement model scales.
> - In such an environment, there are only, ever, "willing users", because, in 
> order to use the network, they are required to agree to the policies.
> 
> This makes the argument you have above, a vacuously defined one. 
> You want to encourage voluntary policy adherence for a non-existent set of 
> otherwise unwilling users.
> 
> I understand your position: you would prefer that {some,all} networks were 
> not employing policies that {you,some people} disagree with.
> I sympathize, but I disagree. What we need are mechanisms that scale.
> My position (personally) is that we find ways to have scalable, technical 
> mechanisms.
> They should allow users (or machine administrators) to be as compliant as 
> they are willing, and no more.
> They should allow networks to enforce their policies, while treading as 
> lightly as possible.
> It should be possible to use technical means to handle this negotiation with 
> little to no user input required.
> The analogy is roughly that of escalation-of-force in law enforcement, 
> starting at a level of "polite requests".
> 
> You can disagree, but I implore you: please don't stand in the way of those 
> wanting to find consensus on scalable, flexible, technical solutions that 
> encompass a wide range of network policies and enforcement needs.
> 
> The main point is, I believe the end result will be mechanisms that allow you 
> to deploy networks that meet your needs, and software that you can configure 
> to bypass such controls, but that neither of those should ever be the default 
> configurations.
> 
> If the results allow you to do what you want/need, and also allow others to 
> do what they want/need, everyone should be happy enough with the result.
> 
> Can we at least agree on this as a desired goal for this work?

Often as an industry we may discuss various solutions that are great for 
oneself but don’t scale when looking at the big picture.  I’m of the feeling 
that not everything should be a standard, even things that look like they might 
be standard-ish.  I could encode many things over TCP over TLS over QUIC over 
HTTP.  I’ve seen unencoded data stored in DNS TXT records that have 
sorted/ordered information so you can do interesting things.

Just because one can do these things doesn’t mean one should, or that the 
entirety of the industry should (or even will).

Goals and motivations are key here, if the goal is to make it such that 
dissidents whose lives may be threatened (this is an example a co-worker always 
uses on me in these types of conversations to support their position) by the 
local regime may face a threatening situation or die as a result of using 
technology, it’s not the fault of the protocol.  Should we improve for every 
corner case like this?  As vixie has pointed it, it may be an innocuous device 
like a chromecast where the ISP provided DNS is horrible.  (I can think of many 
bad devices in the consumer space that break the DNS spec in really unique 
ways).  It’s entirely possible that the appliance works best when not using 
that ISP service, but it is also data leakage to a large global company that 
for reasonable or unreasonable purposes he doesn’t want to transact with.

When we create technologies that can bypass and traverse the existing security 
posture of networks (evil foreign telecoms, where’s my pitchfork) or a coffee 
shop, library, home or large enterprise… expect the work to be held to a higher 
standard.

It may be that there’s not consensus on this topic.  It may be I’m an outlier 
and have been subverted by , but the most 
likely case is there be dragons here and we should tread carefully to not burn 
down the entire place.

- Jared
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Stephen Farrell]

On 20/03/2019 05:46, Brian Dickson wrote:
> On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell 
> wrote:
> 
>>
>>
>> On 20/03/2019 03:17, Brian Dickson wrote:
>>
>>> - If a network operator has any policy that is enforceable, ONLY the
>>> technical policy enforcement model scales.
>>
>> My mail was about my policy for my home network and explicitly said
>> that I do not claim that policy ought be followed by all home networks,
>> never mind other kinds of network. Your argument about scale is not
>> therefore relevant. (At least, not unless you want to give up all
>> argument along the lines of "consider the children.")
>>
> 
> I am saying, that the work product envisioned by participants of the side
> meeting,
> needs to be some framework that scales, regardless of where it gets used.

I'm not at all sure about a "framework" being the output. I do
agree that solutions for networks at all scales are required.

> 
> It does not matter whether any policy does or does not require scalable
> mechanisms.
> What does matter is that there exist networks where the mechanisms need to
> scale.

More than one thing matters. That needs to be kept in mind.

> 
> What is being envisioned and proposed, is a flexible-enough framework, that
> scales.
> 
> If something scales, it scales. If it scales, it won't make it impossible
> to do what you want, tautologically.
> 
> Let's try this using classical logic:
> 
> Suppose there is a rule: "A implies B".
> 
> The negation of that rule is: "Not B implies Not A".
> The negation of that rule is NOT: "Not A implies Not B".
> 
> I believe your argument(s) falls into the "Not A implies Not B" category.
> (I hope I'm mistaken there.)
> 
> However, I am also having a little trouble following your actual meaning.
> More below on my challenge with following what you are saying...
> 
> 
>>
>> My policy, for my network, is as defensible as many others. And that
>> isn't peculiar to home networks.
>>
>>> - In such an environment, there are only, ever, "willing users", because,
>>> in order to use the network, they are required to agree to the policies.
>>
>> Wrong. In my home network, my children and their friends have
>> no real choice to not use the network until they are relatively
>> economically independent. (And in earlier days, they could not
>> have given informed consent in any case, being too young.)
>>
> 
> So, I am trying to understand.
> Does their lack of real choice make them unwilling users?

One could describe it that way. I'm sure many kids might do so;-)
But it's not great terminology.

> Are you arguing that they should be able to bypass whatever rules you have
> for your children?

Most of the "rules" are not enforced by computers, and hence don't
need to be written down precisely. For example, I'd encourage them
to not create accounts on web sites. But I don't try enforce that in
any technical way and accept that sometimes they do end up creating
web accounts. Talking to them about what they're doing and scaring
'em that I could snoop if I was bothered are often sufficient.

> Do you want your children to be able to undetectably use a third party DNS
> resolver, such as DoH,

I don't care about that.

> and access naughty networks 

No, I'd prefer they not. But I have no technical barriers in place
to do such blocking. To the extent that there's a policy at all,
it's defined and (not enforced) purely in the human realm.

> or malware?

Bad question IMO. But in any case, encouraging human behaviour
that doesn't result in malware being executed is IMO more
effective. (E.g. avoiding certain OSes etc.)

> Or do you want to block that particular use case?
> I think their category as "unwilling" is mooted by their being minors and
> not being able to give informed consent.

As I said neither willing nor unwilling are good descriptive terms
for home network users. They are however quite different from
employees in a corporate network (esp in a case like mine with a
technically permissive policy) and that needs to be recognised.

> 
> In any case, if you do want to give them (all of them or some of them)
> access to such third party resolvers, should that not be something
> explicitly under your control?

I don't care about that.

> And should it not be easy to do (where I roughly equate "easy to do" with
> "scalable", for argument purposes).

Ease of use is generally good. I think the challenge for e.g.
browsers, will not reside in networks like mine. I do have
some minor split-horizon issues but nothing that'd break badly
for anyone but me and I know how to handle it.

>> In work environments what you say is also not completely correct,
>> at least in some EU locales, where employees retain rights of
>> various kinds whilst at work using an employer-provided n/w. We
>> don't need to argue the rights and wrongs of that, it just is.
>>
> 
> I think I am also having difficulty with the argument here.

Then feel free to ignore it. My main point is about home networks
but i 

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

[Stephane Bortzmeyer]

On Mon, Mar 11, 2019 at 05:58:13PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 19 lines which said:

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

> It was suggested 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.

I modified the title of the meeting
 because
there is obviously no consensus on the problem or on the
agenda. Anyway, a room is reserved if people want to meet on
wednesday.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop