Re: [DNSOP] [Doh] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Martin Thomson]

On Thu, Apr 5, 2018 at 2:42 AM, Paul Vixie  wrote:
> that would be low fidelity. i need to run clients whose internet experience
> will not be influenced by middleboxes.

So don't include the middlebox in your communications.  It's all the
rage nowadays.

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

[DNSOP] Request to DNSOP chairs for a WGLC on draft-ietf-dnsop-kskroll-sentinel-11.txt

[Geoff Huston]

With the submission of the -11 version of this draft the authors are of the 
view that all WG comments have been discussed, and we think we are now ready 
for a WG Last Call on this document.

Could the chairs kindly consider this request and proceed if they feel it is 
appropriate?

thanks,

   Geoff


> On 5 Apr 2018, at 9:08 am, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : A Root Key Trust Anchor Sentinel for DNSSEC
>Authors : Geoff Huston
>  Joao Silva Damas
>  Warren Kumari
>   Filename: draft-ietf-dnsop-kskroll-sentinel-11.txt
>   Pages   : 16
>   Date: 2018-04-04

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

[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-11.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : A Root Key Trust Anchor Sentinel for DNSSEC
Authors : Geoff Huston
  Joao Silva Damas
  Warren Kumari
Filename: draft-ietf-dnsop-kskroll-sentinel-11.txt
Pages   : 16
Date: 2018-04-04

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user and third parties to determine the trusted key
   state for the root key of the resolvers that handle that user's DNS
   queries.  Note that this method is only applicable for determing
   which keys are in the trust store for the root key.

   There is an example / toy implementation of this at http://www.ksk-
   test.net .

   [ This document is being collaborated on in Github at:
   https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests.  Text
   in square brackets will be removed before publication. ]

   [ NOTE: This version uses the labels "root-key-sentinel-is-ta-", and
   "root-key-sentinel-not-ta-".; older versions of this document used
   "kskroll-sentinel-is-ta-", "kskroll-sentinel-not-ta-", and before that, "_is-ta-", "_not-ta-".
   Also note that the format of the tag-index is now zero-filled
   decimal.  Apolgies to those who have began implmenting.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-11
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-11


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

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

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Tony Finch]

Paul Vixie  wrote:
> Ted Lemon wrote:
> >
> > For your laptop use case, why wouldn't you just have the thing running
> > on the laptop do truncation if the answer is too long?
>
> that would be low fidelity.

I'm interested to know what breaks with something like dnscrypt-proxy or
stubby that works with your proxy.

>From a quick look, I think your proxy doesn't handle AXFR and (more
generally) doesn't map client TCP connections onto server TCP connections,
so it doesn't allow a client to distinguish between servers that have
serial vs concurrent DNS-over-TCP request handling in a way that a truly
high-fidelity tunnel would.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Cromarty, Forth: North 5 to 7, occasionally gale 8 in Forth, becoming variable
3 or 4. Moderate or rough. Sleet, fair later. Good occasionally poor.

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

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Shane Kerr]

Wessels, Duane:
> 
>> On Apr 4, 2018, at 4:01 AM, Shane Kerr  wrote:
>>
>> One issue is that the algorithm proposed requires that the recipient who
>> is generating a digest has to store basically the entire zone before
>> beginning the digest calculation, since it has no way to know if the
>> zone will be delivered in any kind of canonical order.
> 
> Yes.  Certainly for large zones this could be an issue.  We will have to
> find the right balance between complexity and efficiency here.
> 
> I think it makes the most sense to perform a verification when the zone is
> loaded or received by a name server, but it could also be done in an external
> process, such as named-checkzone or ldns-verify-zone.
> 
> 
>>
>> As for specific questions in the draft:
>>
>> * I think that it should be allowed for unsigned zones. If nothing else,
>>  it provides the equivalent of checksum to help prevent truncations or
>>  not properly updated records (missing deletions or additions).
>>
>> * I don't see much benefit in multiple ZONEMD. We generally expect
>>  masters & slaves to co-operate, so they should be able to find
>>  software that has an algorithm that both sides support.
> 
> Yes, but master/slave transfers can already be protected with TSIG.  Perhaps
> the more interesting use case is out-of-band zone distribution.

I have seen zones get broken by transfer in production. I'd say it is
useful any time you transfer zones.

I think an interesting use case is detecting intentional modification by
the master (or a case where the master master is compromised in any way).

If you're just trying to verify the integrity of a file during transfer,
then yes TSIG is sufficient, but then so is a simple sha256sum on a file
that you copy out-of-band.

>> * I think the serial in ZONEMD is helpful. Doesn't it also help prevent
>>  replay attacks?
> 
> You might have to convince me that it does...

Actually you're right. Since the SOA is included in the digest, the
serial in the ZONEMD is not necessary. Probably it should be removed.

>> * I would rather not special-case ZONEMD regarding responding. Even
>>  though it is bigger than most RDATA, large responses seem like a
>>  general problem. OTOH, I won't object too loudly if someone feels very
>>  strongly that this should be an option.
>>
>> A final possible concern is that generating a digest on a large zone
>> might be computationally quite expensive. Indeed it could be used as an
>> attack vector on a hosting provider by using small IXFR to cause large
>> zone digests to be repeatedly calculated. Is it worth exploring the
>> possibility of including multiple ZONEMD in a zone at different names,
>> which digest the part of the zone up to that point? So something like:
> 
> 
> Yes, as currently specified it probably only works well with relatively 
> static zones.
> Again, we'll have to decide where we want to be in the complexity vs 
> efficiency tradeoff.

I don't think that the complexity of having ZONEMD that covers part of a
zone is very high. Certainly from either a master or a slave basically
you just need to reinitialize your hash context and continue rolling
along, right?

Probably given our new camel-busting revolution I should implement the
draft before I make any such claims though...

Cheers,

--
Shane

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 4, 2018, at 2:57 PM, Paul Vixie  wrote:
> no. it uses a DNS response message of rcode SERVFAIL for error signalling. 
> so, it is as transparent as possible, and no more.

Okay.   So the upstream proxy is intended to simply take the "tcp" or "udp" 
indication and do the query using tcp or udp as indicated?   What if I write a 
proxy that doesn't support this behavior—will your downstream proxy fail to 
interoperate with it?   E.g., if it does the query using TCP, or automatically 
fails over to TCP if it gets a truncated response, and therefore returns a long 
response to a UDP query, will bad things happen?

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ted Lemon wrote:

On Apr 4, 2018, at 2:35 PM, Paul Vixie > wrote:

could this be done with a resolver using non-proxy DOH as a transport
to its forwarder? sure. but that puts semantic intelligence in the
middle, which will introduce configuration, logging, monitoring,
diagnosis, upgrade, and patching costs. i don't want those here.


So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the
destination port?


no. it uses a DNS response message of rcode SERVFAIL for error 
signalling. so, it is as transparent as possible, and no more.


--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 4, 2018, at 2:35 PM, Paul Vixie  wrote:
> could this be done with a resolver using non-proxy DOH as a transport to its 
> forwarder? sure. but that puts semantic intelligence in the middle, which 
> will introduce configuration, logging, monitoring, diagnosis, upgrade, and 
> patching costs. i don't want those here.

So essentially this is {UDP | TCP}-over-HTTPS, with constraints on the 
destination port?


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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ted Lemon wrote:

On Apr 4, 2018, at 1:23 PM, Paul Vixie > wrote:

you've cut too much context. my answer was to "just truncate". your
followup is about "which middlebox."


Here's what I was replying to:


For your laptop use case, why wouldn't you just have the thing running
on the laptop do truncation if the answer is too long?


that would be low fidelity. i need to run clients whose internet
experience will not be influenced by middleboxes.


So you've said that the client's experience will be influenced by
middleboxes.


i intended this to be heard as "will otherwise be influenced by 
middleboxes".



I'm trying to understand what the scenario is where this
would happen. Hence my diagram:

LAPTOPDNS-over-https-proxy<---link b--->Full Service
Resolver<---internet--->Authoritative servers

That is, what is the problem you are trying to avoid that requires the
proxy to transparently tunnel rather than simply answering the query?


the proxy is transparent. from https://github.com/BII-Lab/DNSoverHTTP:


The proxy service does not interpret the DNS query or response in any
way. It could be DNS, EDNS, or something not yet invented at the time
of this writing. The only requirement is that each request message
solicits exactly one response message. If anything at all goes wrong
with the proxy service, the stub client will hear a DNS SERVFAIL
response.


i intend that the endpoints (who are real dns speakers and listeners) be 
able to evolve, or never evolve, according to their own drumbeats.


the real middlebox that's otherwise in the way is in my hotel room or 
coffee shop, and knows that udp/53 is a service address, and 
policy-routes my dns traffic to its own agent, which thinks it knows 
what DNS has to look like, and can't handle modern (1999-era) extensions 
like EDNS.


by putting these messages inside https (a virtual high fidelity middle 
box), i make them invisible to the hotel's physical low fidelity middle 
box. and by respecting the originator's transport choice, i remain 
transparent to its strategy to use edns-512, edns-1280, tcp, dns, and so 
on, in whatever order it wants to do.


could this be done with a resolver using non-proxy DOH as a transport to 
its forwarder? sure. but that puts semantic intelligence in the middle, 
which will introduce configuration, logging, monitoring, diagnosis, 
upgrade, and patching costs. i don't want those here.


--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 4, 2018, at 1:23 PM, Paul Vixie  wrote:
> you've cut too much context. my answer was to "just truncate". your followup 
> is about "which middlebox."

Here's what I was replying to:

>> For your laptop use case, why wouldn't you just have the thing running
>> on the laptop do truncation if the answer is too long?
> 
> that would be low fidelity. i need to run clients whose internet experience 
> will not be influenced by middleboxes.

So you've said that the client's experience will be influenced by middleboxes.  
 I'm trying to understand what the scenario is where this would happen.   Hence 
my diagram:

LAPTOPDNS-over-https-proxy<---link b--->Full Service 
Resolver<---internet--->Authoritative servers

That is, what is the problem you are trying to avoid that requires the proxy to 
transparently tunnel rather than simply answering the query?

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ted Lemon wrote:

On Apr 4, 2018, at 12:42 PM, Paul Vixie > wrote:

that would be low fidelity. i need to run clients whose internet
experience will not be influenced by middleboxes.


I'm having trouble figuring out where a middlebox would be here that
would reduce fidelity. Isn't the point of what you're doing to
completely bypass any middleboxes that are in the way?

I think the diagram looks like this:

LAPTOPDNS-over-https-proxy<---link b--->Full Service
Resolver<---internet--->Authoritative servers

Where is the middlebox that's going to reduce fidelity?


you've cut too much context. my answer was to "just truncate". your 
followup is about "which middlebox."


--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 4, 2018, at 12:42 PM, Paul Vixie  wrote:
> that would be low fidelity. i need to run clients whose internet experience 
> will not be influenced by middleboxes.

I'm having trouble figuring out where a middlebox would be here that would 
reduce fidelity.   Isn't the point of what you're doing to completely bypass 
any middleboxes that are in the way?

I think the diagram looks like this:

LAPTOPDNS-over-https-proxy<---link b--->Full Service 
Resolver<---internet--->Authoritative servers

Where is the middlebox that's going to reduce fidelity?

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ben Schwartz wrote:

If the stub and forwarder are both on your laptop, why do you need to
truncate?  Local UDP should have extremely large MTU.


i know this was addressed to me, but i didn't mention truncation, so 
it's to me a nonsequitur.


--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Wessels, Duane]

> On Apr 4, 2018, at 6:15 AM, Tony Finch  wrote:
> 
> A couple of thoughts/questions:
> 
> The sorting algorithm specifies CLASS as part of the sort key. This is
> fine, but slightly redundant since all records in a zone have the same
> class :-)

Okay.  I managed to convince myself that zone files could contain multiple
classes, but looking now I see in 1035 it says "All RRs in the file should
have the same class."


> 
> Regarding efficiency, I wonder if there would be much win from giving it a
> bit more of a tree structure, e.g.
> 
> ; similar ordering to RRSIG calculation
> digest_RRset(n,r) = digest_algorithm( RRsig(i,1) | ... | RRsig(i,si) |
>  RR(i,1) | ... | RR(i,ri) )
> 
> digest_owner(n) = digest_algorithm( digest_RRset(n,1) | ... )
> 
> digest = digest_algorithm( digest_owner(1) | ... )
> 
> So when updating a zone, you can just recalculate the digests for the
> affected owner names, then re-digest the string of digests. This should be
> faster for signed zones, but it might not be a win for unsigned zones (a
> SHA256 is about the same size as an A record).
> 
> (Following the hierarcial structure of owner names is probably not worth
> it given the flatness of most zones.)
> 
>> Is it worth exploring the possibility of including multiple ZONEMD in a
>> zone at different names, which digest the part of the zone up to that
>> point?
> 
> Also a good idea :-) It probably needs to look a bit more like NSEC to
> make it explicit which owners are covered.

My initial reaction is that I'm not fond of the complexity, but would like
to hear if people think zone digest is useful for the types of zones where
recalculation is a significant concern.

DW

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Dave Lawrence wrote:

Martin Thomson writes:

Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.


I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.


yes.

--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Martin Thomson wrote:

On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman  wrote:

Martin: Are you saying that you want DOH to remove the optional parameter from 
the application/dns-udpwireformat registration? If so, what do you propose for 
the DNSOP WG?


Right now, abandon draft-ietf-dnsop-dns-wireformat-http.  But I'll
concede that I'm probably missing something.


the use case is not well-expressed. as a co-author, i apologize.


By my current understanding, draft-ietf-dnsop-dns-wireformat-http is
indistinguishable from a specific implementation of
draft-ietf-doh-dns-over-https.  That is, if a DOH server wanted to
service all its queries by forwarding requests to a resolver [1], I
can't see how that would be disallowed by DOH, and that's exactly what
draft-ietf-dnsop-dns-wireformat-http appears to describe.


it's a high-fidelity virtual middlebox, to work around low-fidelity 
actual middleboxes. it is not a new dns transport protocol, which would 
require client and server changes. dns-over-https is a thin drop-in.


--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Wessels, Duane]

> On Apr 4, 2018, at 4:01 AM, Shane Kerr  wrote:
> 
> One issue is that the algorithm proposed requires that the recipient who
> is generating a digest has to store basically the entire zone before
> beginning the digest calculation, since it has no way to know if the
> zone will be delivered in any kind of canonical order.

Yes.  Certainly for large zones this could be an issue.  We will have to
find the right balance between complexity and efficiency here.

I think it makes the most sense to perform a verification when the zone is
loaded or received by a name server, but it could also be done in an external
process, such as named-checkzone or ldns-verify-zone.


> 
> As for specific questions in the draft:
> 
> * I think that it should be allowed for unsigned zones. If nothing else,
>  it provides the equivalent of checksum to help prevent truncations or
>  not properly updated records (missing deletions or additions).
> 
> * I don't see much benefit in multiple ZONEMD. We generally expect
>  masters & slaves to co-operate, so they should be able to find
>  software that has an algorithm that both sides support.

Yes, but master/slave transfers can already be protected with TSIG.  Perhaps
the more interesting use case is out-of-band zone distribution.

> 
> * I think the serial in ZONEMD is helpful. Doesn't it also help prevent
>  replay attacks?

You might have to convince me that it does...

> 
> * I would rather not special-case ZONEMD regarding responding. Even
>  though it is bigger than most RDATA, large responses seem like a
>  general problem. OTOH, I won't object too loudly if someone feels very
>  strongly that this should be an option.
> 
> A final possible concern is that generating a digest on a large zone
> might be computationally quite expensive. Indeed it could be used as an
> attack vector on a hosting provider by using small IXFR to cause large
> zone digests to be repeatedly calculated. Is it worth exploring the
> possibility of including multiple ZONEMD in a zone at different names,
> which digest the part of the zone up to that point? So something like:


Yes, as currently specified it probably only works well with relatively static 
zones.
Again, we'll have to decide where we want to be in the complexity vs efficiency 
tradeoff.

DW

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 4, 2018, at 11:49 AM, Paul Vixie  wrote:
> this is a far thinner solution than a full-service resolver, which would 
> require local configuration and monitoring and so on, as well as topology 
> stability that can't be guaranteed.

For your laptop use case, why wouldn't you just have the thing running on the 
laptop do truncation if the answer is too long?   I admit that this is more 
code, but it's not a lot more code, and what you're doing instead is pretty 
hacky.

The fact that it's not required to implement doesn't mean that it doesn't 
contribute to the camel problem.

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ted Lemon wrote:

On Apr 4, 2018, at 11:37 AM, Paul Vixie > wrote:

there's code that implements this. there are people using it. there
will be more of both. a standard will mean greater interoperability.


Why was the code written? Why are they using this?


where the client can't be upgraded to DOH, and the network can't be 
upgraded to add VPN's, this allows a name server to be reachable with 
full fidelity (no middleboxes, so EDNS works) and better-than-cleartext 
privacy. i use it on my laptop when in a hotel room or coffee shop.



What is it about this
solution that makes it preferable, for their use case, to a smart proxy
that is itself a full-service resolver and thus shouldn't tunnel
information about the query transport?


this is a far thinner solution than a full-service resolver, which would 
require local configuration and monitoring and so on, as well as 
topology stability that can't be guaranteed.



Given Bert's talk on camels, I think these are questions that are worth
asking, and the answer shouldn't be "because."


this would never be part of the mandatory-to-implement "DNS core".

--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ted Lemon]

On Apr 4, 2018, at 11:37 AM, Paul Vixie  wrote:
> there's code that implements this. there are people using it. there will be 
> more of both. a standard will mean greater interoperability.

Why was the code written?   Why are they using this?   What is it about this 
solution that makes it preferable, for their use case, to a smart proxy that is 
itself a full-service resolver and thus shouldn't tunnel information about the 
query transport?

Given Bert's talk on camels, I think these are questions that are worth asking, 
and the answer shouldn't be "because."

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ted Lemon wrote:

On Apr 4, 2018, at 10:54 AM, Paul Vixie > wrote:

this is not a service. DOH is a service. this is a proxy, which i
would like to have be interoperable. please don't ask me to change
what i want to build; that would be out-of-scope.


Maybe another question to ask is "okay, Paul wants to build this, but
why does the IETF need to standardize it?"


same as for ECS: not universally popular, but better if interoperable.


I don't mean that the answer should be "it doesn't," but rather that I
don't actually see why this is valuable, and maybe I'm not the only one
who needs to hear more of a sales pitch.


there's code that implements this. there are people using it. there will 
be more of both. a standard will mean greater interoperability.


--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

ray, i won't engage on the question, should i want to do this. the 
working group mantra is interoperability -- as in, if you want to do 
this, here's an interoperable way. i'm not asking that the working group 
ratify the intent, or recommend the method. (as went ECS.)


the proxy is transparent. we list it in resolv.conf or as a forwarder. 
it regenerates the queries on the far side. it has to differentiate 
between tcp and udp because the unmodified client is making strategy 
decisions and implementing those using that transport choice.


this is not a service. DOH is a service. this is a proxy, which i would 
like to have be interoperable. please don't ask me to change what i want 
to build; that would be out-of-scope.


paul

re:

Ray Bellis wrote:

On 04/04/2018 13:20, Paul Vixie wrote:


tcp and udp are the two ways a query might have reached the
initiating proxy, and that distinction is the only thing the
responding proxy needs to know.


I disagree, I don't think that transport protocols should continue to be
used as things that should be used for policy decisions.

Per my previous message, they were a suitable proxy (no pun intended)
for "this came from an unspoofable address", or "this channel can handle
large responses" but there are other ways to achieve that now that
aren't strictly transport.

For example, presence of EDNS cookies satisfies the "unspoofable
address" and therefore would permit RRL to be skipped for that client,
but "UDP with Cookies" isn't a transport.

[I appreciate that this isn't the best example because that cookie
*might* get all the way through to the backend server anyway.  But it
also might not].


if DOH becomes a standard transport, then we could add that
identifier as well -- but i don't think a client capable of DOH is
going to be using this particular proxy method.


We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
DNS-over-QUIC too.  None of those are true "transports", but server
operators may wish to make policy decisions based on the resulting
meta-properties of them.

Ray

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


--
P Vixie

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ray Bellis]

On 04/04/2018 13:20, Paul Vixie wrote:

> tcp and udp are the two ways a query might have reached the
> initiating proxy, and that distinction is the only thing the
> responding proxy needs to know.

I disagree, I don't think that transport protocols should continue to be
used as things that should be used for policy decisions.

Per my previous message, they were a suitable proxy (no pun intended)
for "this came from an unspoofable address", or "this channel can handle
large responses" but there are other ways to achieve that now that
aren't strictly transport.

For example, presence of EDNS cookies satisfies the "unspoofable
address" and therefore would permit RRL to be skipped for that client,
but "UDP with Cookies" isn't a transport.

[I appreciate that this isn't the best example because that cookie
*might* get all the way through to the backend server anyway.  But it
also might not].

> if DOH becomes a standard transport, then we could add that 
> identifier as well -- but i don't think a client capable of DOH is
> going to be using this particular proxy method.

We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
DNS-over-QUIC too.  None of those are true "transports", but server
operators may wish to make policy decisions based on the resulting
meta-properties of them.

Ray

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Mark Andrews]

> On 4 Apr 2018, at 8:26 pm, Matthijs Mekking  wrote:
> 
> Hi Frederico,
> 
> On 04-04-18 03:32, Frederico A C Neves wrote:
>> Hi Matthijs,
>> On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
>>> Hi Frederico,
>>> 
>>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
 I was looking at our server to evaluate the MIXFR implementation and
 it seams to me that the current text covering dnssec aware client
 logic don't take in account that a posterior record at the addition
 section, by an MIXFR DNSSEC aware server, will implicitly replace the
 RRSIG RRset.
>>> 
>>> I am unclear what case you are covering.
>> Any situation that you have an updated RRset. It is implicit that
>> you'll have to update the signature, so I was arguing that this is
>> afterward covered by 3.6 Replace a RRset. My "simplified" logic take
>> this in account to don't impose this extra logic at the client for
>> updated RRsets, only for removed RRsets, explicit or when a removal of
>> RR causes it.
> 
> I get it now, thanks for clarifying.
> 
> Still, I think the savings in complexity is minimal, since the logic should 
> exist for RR deletion, so it's a small effort to also enable it for RR 
> addition.
> 
> Looking at your examples, there is very little difference on the wire. So it 
> would only be for client logic purposes I assume. I doubt that the logic is 
> simplified though:
> 
> If you want to prevent implicit RRSIG deletion in the "Replace RRset" case, 
> you now have to have logic to verify there is no RR in the addition section 
> of the MIXFR.
> 
> Note that implicit RRSIG deletion is idempotent, so it does not matter if two 
> RRs in the MIXFR trigger it.

Not if you are processing the additions on a RR by RR basis. You can add a new 
RRSIG
before you add the covering RR.  You need to perform two passes over the 
addition section.
1 - to perform implicit deletions.
2 - to perform explicit additions.

Note there are some RR deletions / addition pairs that DO NOT change RRSIGs. 
e.g. case changes
in domain names that are subject to canonicalisation.  There is no requirement 
to regenerate
RRSIGs for such changes though most implementations will do so.


> Best regards,
> 
> Matthijs
> 
> 
>> So the actual difference on the wire is one server replacing the RRSIG
>> and the other adding it. For the client processing is RRSIG removal
>> logic only at RRset removal in one case and at any change for the
>> other. Bellow a zone at serial 1 and 2 and the two MIXFR versions.
>> example. IN  SOA serial=1
>> example. IN  RRSIG SOA
>> a.example.   IN  A   192.0.2.1
>> a.example.   IN  RRSIG A
>> b.example.   IN  A   192.0.2.2
>> b.example.   IN  A   192.0.2.3
>> b.example.   IN  RRSIG A
>> example. IN  SOA serial=2
>> example. IN  RRSIG SOA
>> b.example.   IN  A   192.0.2.3
>> b.example.   IN  A   192.0.2.4
>> b.example.   IN  RRSIG A
>> c.example.   IN  A   192.0.2.5
>> c.example.   IN  RRSIG A
>> # "simplified MIXFR"
>> example. IN  SOA serial=2
>> example. IN  SOA serial=1
>> a.example.   ANY A
>> b.example.   IN  A   192.0.2.2
>> example. IN  SOA serial=2
>> b.example.   IN  A   192.0.2.4
>> b.example.   ANY RRSIG A > c.example.IN  A   192.0.2.5
>> c.example.   IN  RRSIG A
>> example. IN  SOA serial=2
>> # "implicit RRSIG removal at any change"
>> example. IN  SOA serial=2
>> example. IN  SOA serial=1
>> a.example.   ANY A
>> b.example.   IN  A   192.0.2.2
>> example. IN  SOA serial=2
>> b.example.   IN  A   192.0.2.4
>> b.example.   IN  RRSIG A
>> c.example.   IN  A   192.0.2.5
>> c.example.   IN  RRSIG A
>> example. IN  SOA serial=2
>>> 
 Logic could be simplified only to Deletions of RRs, when they conclude
 a removal of a RRset, or RRsets by itself.
>>> 
>>> No, also if there is an RR addition, it means the RRset has changed, so
>>> existing RRSIG records can be implicitly removed.
>>> 
>> That is true but in this case you imply that it will be later added. I
>> was proposing to replace it.
 All the other cases, addition or replacement, will be covered
 automatically by an addition or replace of a RRSIG RRset. There is no
 need to extra client logic to remove RRSIG, at addition of a RR, and
 at deletion of a RR if it not remove the RRset.
>>> 
>>> Note there is no such thing as an RRSIG RRset. I tried to clarify this
>>> in the terminology bis document:
>> So how do you call, two RR for the same name, type and class in a
>> double signed zone? Never mind I was not aware of this, thanks! Change
>> "a RRSIG RRset" by "any RRSIGs" and the logic still stands.
>>> 
>>>https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html
>>> 
>>> Note that adding an RRSIG is 

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Tony Finch]

Shane Kerr  wrote:
> Wessels, Duane:
> >
> > This draft proposes a technique and new RR type for calculating and
> > verifying a message digest over the contents of a zone file.  Using
> > this technique, the recipient of a zone containing the new RR type can
> > verify it for completeness and correctness, especially so when the
> > zone is signed.  We welcome your feedback on this document.
>
> I think this is a great idea. Certainly one of the things that we were
> missing in the Yeti project was a way to confirm that the contents of
> the root zone transfered from any particular master were actually the
> correct version, so this fills a real need.

Yep, interesting.

A couple of thoughts/questions:

The sorting algorithm specifies CLASS as part of the sort key. This is
fine, but slightly redundant since all records in a zone have the same
class :-)

Regarding efficiency, I wonder if there would be much win from giving it a
bit more of a tree structure, e.g.

; similar ordering to RRSIG calculation
digest_RRset(n,r) = digest_algorithm( RRsig(i,1) | ... | RRsig(i,si) |
  RR(i,1) | ... | RR(i,ri) )

digest_owner(n) = digest_algorithm( digest_RRset(n,1) | ... )

digest = digest_algorithm( digest_owner(1) | ... )

So when updating a zone, you can just recalculate the digests for the
affected owner names, then re-digest the string of digests. This should be
faster for signed zones, but it might not be a win for unsigned zones (a
SHA256 is about the same size as an A record).

(Following the hierarcial structure of owner names is probably not worth
it given the flatness of most zones.)

> Is it worth exploring the possibility of including multiple ZONEMD in a
> zone at different names, which digest the part of the zone up to that
> point?

Also a good idea :-) It probably needs to look a bit more like NSEC to
make it explicit which owners are covered.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Plymouth, Biscay: West 5 to 7, occasionally gale 8 at first, backing south 3
or 4, occasionally 5 later. Rough or very rough. Showers, then fair. Good.

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Ray Bellis wrote:

On 04/04/2018 04:39, Dave Lawrence wrote:


I think that's right.  -05 with the original_transport optional
parameter accommodates the aims of that other draft.


but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).


tcp and udp are the two ways a query might have reached the initiating 
proxy, and that distinction is the only thing the responding proxy needs 
to know. if DOH becomes a standard transport, then we could add that 
identifier as well -- but i don't think a client capable of DOH is going 
to be using this particular proxy method.


--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

[Shane Kerr]

Duane,

Wessels, Duane:
> 
> This draft proposes a technique and new RR type for calculating and verifying 
> a message digest over the contents of a zone file.  Using this technique, the 
> recipient of a zone containing the new RR type can verify it for completeness 
> and correctness, especially so when the zone is signed.  We welcome your 
> feedback on this document.

I think this is a great idea. Certainly one of the things that we were
missing in the Yeti project was a way to confirm that the contents of
the root zone transfered from any particular master were actually the
correct version, so this fills a real need.

One issue is that the algorithm proposed requires that the recipient who
is generating a digest has to store basically the entire zone before
beginning the digest calculation, since it has no way to know if the
zone will be delivered in any kind of canonical order. It might be nice
to have some way to signal that. I'm not sure exactly how, and possibly
that belongs in a separate document (maybe we can tack it onto MIXFR?),
but it seems like a potential problem as it adds extra work (possibly
re-reading the entire zone an extra time along with the associated I/O,
memory consumption, and unneeded latency due to checking).

As for specific questions in the draft:

* I think that it should be allowed for unsigned zones. If nothing else,
  it provides the equivalent of checksum to help prevent truncations or
  not properly updated records (missing deletions or additions).

* I don't see much benefit in multiple ZONEMD. We generally expect
  masters & slaves to co-operate, so they should be able to find
  software that has an algorithm that both sides support.

* I think the serial in ZONEMD is helpful. Doesn't it also help prevent
  replay attacks?

* I would rather not special-case ZONEMD regarding responding. Even
  though it is bigger than most RDATA, large responses seem like a
  general problem. OTOH, I won't object too loudly if someone feels very
  strongly that this should be an option.

A final possible concern is that generating a digest on a large zone
might be computationally quite expensive. Indeed it could be used as an
attack vector on a hosting provider by using small IXFR to cause large
zone digests to be repeatedly calculated. Is it worth exploring the
possibility of including multiple ZONEMD in a zone at different names,
which digest the part of the zone up to that point? So something like:

a.example.com ...
 .
 .
 .
n.example.com ...
n.example.com ... ZONEMD ...  ; covers a-n
 .
 .
 .
z.example.com ...
example.com ... ZONEMD ... ; covers o-z

(Sorry this needs to be more carefully thought through, but that's the
basic idea.)

Cheers,

--
Shane

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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking]

Joe,

Thanks for sharing your concerns.

On 04-04-18 05:31, Joe Abley wrote:

On Apr 3, 2018, at 21:32, Frederico A C Neves 
wrote:


On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking
wrote: Hi Frederico,


On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was
looking at our server to evaluate the MIXFR implementation and 
it seams to me that the current text covering dnssec aware

client logic don't take in account that a posterior record at
the addition section, by an MIXFR DNSSEC aware server, will
implicitly replace the RRSIG RRset.


I am unclear what case you are covering.


Any situation that you have an updated RRset. It is implicit that 
you'll have to update the signature, so I was arguing that this is 
afterward covered by 3.6 Replace a RRset. My "simplified" logic

take this in account to don't impose this extra logic at the client
for updated RRsets, only for removed RRsets, explicit or when a
removal of RR causes it.


I have not been reading this thread in depth and so I have not
commented up until now. But I sense that there is a proposed shift of
responsibility for coherency in the contents of a zone, specifically
with resapect to DNSSEC. Quite possibly I am wrong, in which case I
will enjoy being told as much.


I am happy to entertain you by telling that there is no shift in 
responsibility for coherency in the contents of a zone.


We are merely trying to come up with a more sophisticated syntax such 
that the primary has to use less bytes to achieve zone consistency.




If I am a zone administrator, responsible for the self-consistent
contents of my zone, and I make a mistake, the behaviour today (with
zones distributed by AXFR, IXFR, rsync, ftp, avian carrier) is that a
DNS zone is a DNS zone and the RRSets contained within are simply
that, no appreciation, understanding or accommodation of DNSSEC
required.


I see your argument. On the other hand, if you make a mistake with 
DNSSEC you are in trouble anyway.




The line of thinking inherent in the lowest quoted paragraph above
suggests that distribution of sets of RRSets (together forming a
zone) must with this new transfer mechanism be completed with
semantic appreciation for the relationship between non-RRSIG-type
RRSets and the corresponding RRSIG-type RRSets that accompany them in
a signed zone. This worries me.

The protocol requirements for DNSSEC as described in RFC 4035 are
non-trivial to implement already (cf. the treatment of RRSets in a
response with their accompanying RRSIG RRSets as an atomic unit in
the cache, to be expired together regardless of differences in TTL)
and I don't think we want to extend them without good reason.


Note that this does not affect resolvers and caches: zone transfers are 
between authoritative name servers only.


I am determined to back the specification with an implementation, 
especially after the camel is our new favorite animal, so hopefully that 
will take away your concerns regarding implementation complexity.




If we expect MIXFR (or whatever it is eventually called) to behave
differently in this respect to AXFR, IXFR or any number of
out-of-band transfer mechanisms, we should have a good reason for it.
I don't know that I see one, yet.


It is zone transfer size. It can be quite large with DNSSEC (zone 
re-sign, NSEC3 resalt). To quote someone: Reducing the amount of data, 
is the only way to keep up with our current and future workloads.


Best regards,
  Matthijs





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

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking]

Hi Frederico,

On 04-04-18 03:32, Frederico A C Neves wrote:

Hi Matthijs,

On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:

Hi Frederico,

On 03/29/2018 08:45 PM, Frederico A C Neves wrote:

I was looking at our server to evaluate the MIXFR implementation and
it seams to me that the current text covering dnssec aware client
logic don't take in account that a posterior record at the addition
section, by an MIXFR DNSSEC aware server, will implicitly replace the
RRSIG RRset.


I am unclear what case you are covering.


Any situation that you have an updated RRset. It is implicit that
you'll have to update the signature, so I was arguing that this is
afterward covered by 3.6 Replace a RRset. My "simplified" logic take
this in account to don't impose this extra logic at the client for
updated RRsets, only for removed RRsets, explicit or when a removal of
RR causes it.


I get it now, thanks for clarifying.

Still, I think the savings in complexity is minimal, since the logic 
should exist for RR deletion, so it's a small effort to also enable it 
for RR addition.


Looking at your examples, there is very little difference on the wire. 
So it would only be for client logic purposes I assume. I doubt that the 
logic is simplified though:


If you want to prevent implicit RRSIG deletion in the "Replace RRset" 
case, you now have to have logic to verify there is no RR in the 
addition section of the MIXFR.


Note that implicit RRSIG deletion is idempotent, so it does not matter 
if two RRs in the MIXFR trigger it.


Best regards,

Matthijs



So the actual difference on the wire is one server replacing the RRSIG
and the other adding it. For the client processing is RRSIG removal
logic only at RRset removal in one case and at any change for the
other. Bellow a zone at serial 1 and 2 and the two MIXFR versions.

example.IN  SOA serial=1
example.IN  RRSIG SOA
a.example.  IN  A   192.0.2.1
a.example.  IN  RRSIG A
b.example.  IN  A   192.0.2.2
b.example.  IN  A   192.0.2.3
b.example.  IN  RRSIG A

example.IN  SOA serial=2
example.IN  RRSIG SOA
b.example.  IN  A   192.0.2.3
b.example.  IN  A   192.0.2.4
b.example.  IN  RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A


# "simplified MIXFR"
example.IN  SOA serial=2
example.IN  SOA serial=1
a.example.  ANY A
b.example.  IN  A   192.0.2.2
example.IN  SOA serial=2
b.example.  IN  A   192.0.2.4
b.example.  ANY RRSIG A > c.example. IN  A   192.0.2.5
c.example.  IN  RRSIG A
example.IN  SOA serial=2

# "implicit RRSIG removal at any change"
example.IN  SOA serial=2
example.IN  SOA serial=1
a.example.  ANY A
b.example.  IN  A   192.0.2.2
example.IN  SOA serial=2
b.example.  IN  A   192.0.2.4
b.example.  IN  RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A
example.IN  SOA serial=2




Logic could be simplified only to Deletions of RRs, when they conclude
a removal of a RRset, or RRsets by itself.


No, also if there is an RR addition, it means the RRset has changed, so
existing RRSIG records can be implicitly removed.



That is true but in this case you imply that it will be later added. I
was proposing to replace it.

All the other cases, addition or replacement, will be covered
automatically by an addition or replace of a RRSIG RRset. There is no
need to extra client logic to remove RRSIG, at addition of a RR, and
at deletion of a RR if it not remove the RRset.


Note there is no such thing as an RRSIG RRset. I tried to clarify this
in the terminology bis document:


So how do you call, two RR for the same name, type and class in a
double signed zone? Never mind I was not aware of this, thanks! Change
"a RRSIG RRset" by "any RRSIGs" and the logic still stands.



https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html

Note that adding an RRSIG is different than replacing an RRSIG.


Ok, but we could achive the same end result with both logics and
operations.




This is documented as issue #10 and includes proposed text.

https://github.com/matje/mixfr/issues/10


I think it makes more sense to keep the text as is, that is when
changing an RRset implicitly remove the corresponding RRSIG records. I
am opposed to only removing corresponding RRSIG on a RR deletion.



I think my version is easyer imposing less checks on clients but I can
live with the current text

I just realized the draft needs a new example for 4.2. The current one
is based on "Delete All RRsets of a Type". This operations was removed
in the current version of the draft.


Best regards,
Matthijs


Fred

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ray Bellis]

[added DOH WG to the cc:]

On 04/04/2018 04:39, Dave Lawrence wrote
> I think that's right.  -05 with the original_transport optional
> parameter accommodates the aims of that other draft.

but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).

Ray

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

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Ray Bellis]

On 04/04/2018 04:39, Dave Lawrence wrote:

> I think that's right.  -05 with the original_transport optional
> parameter accommodates the aims of that other draft.

but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy decisions
based on the meta-properties of the original request and its transport
(whether that be a "real" tranport protocol like UDP or TCP or a
pseudo-transport like DNS-o-TLS, or DNS-o-QUIC, etc).

Ray

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

Re: [DNSOP] raising the bar: requiring implementations

[Petr Špaček]

On 29.3.2018 22:59, Phillip Hallam-Baker wrote:
> On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf  > wrote:
> 
> 
> Should we refuse to document such things because they’re not in
> well-known open source codebases, or have otherwise not passed tests
> of goodness?
> 
> It’s not a rhetorical question. Given that people are extending the
> protocol outside of the IETF or any other formal process, in order
> to solve their own technical and business problems, it makes sense
> to ask ourselves periodically whether we should be encouraging them,
> trying to stop them, or something in between.
> 
> 
> ​There are in fact precedents for doing something of the sort. But not
> ones that I think we should follow.
> 
> DNSSEC would have been implemented as part of the VeriSign ATLAS roll
> out. The reason it was not was it simply could not be deployed using the
> tech available with the spec as it was at the time without a major
> increase in cost and complexity.
> 
> A blanket requirement for open source implementations may well have the
> same effect.
> 
> Operating systems at Internet scale is vastly more complex than running
> systems at network scale. It is not just the genius of the original
> Internet designers that has allowed the Internet to scale from 100 nodes
> to 10 billion. There is a vast amount of unseen engineering work that is
> equally heroic and some of that infrastructure comes with some very
> specific constraints.
> 
> Some of the most useful work in IETF is making closed systems more open.
> Often those projects require some extra slots to carry information that
> is needed for some legacy system. I see no value to saying folk can't
> have a smooth transition path from proprietary to open.

I do not see a problem. First there needs to be running code and RFC
will follow. It IMHO does not make much sense the other way around, and
we will suffer for next decade because we did not follow this rule in
the past.

-- 
Petr Špaček  @  CZ.NIC

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

Re: [DNSOP] raising the bar: requiring implementations

[Petr Špaček]

On 29.3.2018 22:05, Mukund Sivaraman wrote:
> On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote:
>>
>> On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman  wrote:
>>
>>> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
 I would say that most things we have adopted in the past few years do have
 some implementations to reference.
 Not when drafts are adopted, but generally before we head to WGLC I've
 always wanted to see someone
 who implemented the option in some manner.

 But yes, agree.
>>>
>>> I'd raise the bar even higher, to see complete implementation in a major
>>> open source DNS implementation when it applies. Sometimes implementation
>>> problems are very revealing (client-subnet should have gone through
>>> this).
>>
>> This is actually quite a good example of another problem:
>> Client-subnet was documented for Informational purposes; it was
>> already in wide use in the public internet and had an EDNS opt code
>> codepoint allocated from the IANA registry.
>>
>> Nothing that happened in DNSOP or the IETF changed that, and I
>> strongly suspect nothing that happened in DNSOP or the IETF could have
>> changed it.
> 
> We found issues in the client-subnet description (in the draft stages)
> that were corrected before it became RFC - this involved some behavioral
> changes. However, the opportunity was not given to address fundamental
> design issues, so what's in the RFC largely documents the
> implementations preceding it and still has issues. I didn't think
> client-subnet was in wide use when it came to dnsop. Even today it
> doesn't look like it's in wide use.
> 
> You have asked an interesting question, because what happens if
> something is already being used and there's no chance to update/correct
> problems because that would make it a different protocol?
> 
> IMO, we should not put anything through dnsop that does not allow
> reviewing and correcting problems. It is pointless for dnsop to shepherd
> a draft to RFC when there's no possibility to influence it.
> 
> During later stages of the draft via dnsop, we implemented client-subnet
> (resolver side) and found various problems. Some of these were addressed
> in the draft, but it was revealing how poor the state of the
> design/draft was. This is why I strongly suggest: A code contribution of
> a _complete implementation_ of everything described in the draft to one
> of the open source DNS implementations should come sometime during
> adoption, so that
> 
> (a) issues in production implementation are revealed
> 
> (b) it can be tried in the real world to understand how it behaves.
> 
> As you're a co-chair:
> 
> When Bert did that Camel presentation, I felt hooray, here's one of us
> who's talking about what the steady churn of ideas and RFCs is doing to
> DNS implementations. We finish implementing one draft and at almost
> breathless pace, a few more drafts queue up. It's not sustainable,
> esp. as all the existing features also need to be maintained for years.
> 
> Introducing a new RR type that doesn't involve additional processing is
> relatively trivial and nobody objects about it.
> 
> Introducing something like TCP pipelining, or rather, out-of-order query
> processing, may seem trivial when describing the change, but
> implementing it may need fundamental restructuring of the
> implementation. Proper implementation of client-subnet needs change
> everywhere within a nameserver from the client message parsing code to
> the data structures used for cache, and how cache lifetime is managed.
> 
> Implementations are being stretched and bent 5 different ways to adapt
> to the length and breadth of all these newfangled DNS items that
> literally are showing up at an alarming pace.
> 
> Bert really hit the spot at the right time. Something needs to be done
> to check what becomes an RFC. A good way is to require an open source
> implementation. If draft authors cannot supply that or convince an open
> source implementation to write support for it, it can go back to where
> it came from.

I tend to agree with Mukund. What's the point of doing standards, if
there is nothing to test against?

Let's imagine that e.g. Cisco and Google propose a brand new feature of
DNS protocol, but its implementation is available only for their
enterprise customers. Why should The Internet bother?

DNS is/was mostly open-source place, and I have a feeling that RFCs are
in the end closely followed only by open-source implementations anyway,
and that rest of the DNS players do whatever they want.
Examples:
- Empty non-terminals vs. Akamai
- EDNS vs. Cisco middleboxes
- EDNS ignorance (auth side) vs. Google
- 

So, why should we (as dnsop) bother "ratifying" something for the big
folks who simply do not care enough to follow what we already published?

I can see parallel with TLS group where "big guys" continually submit
various drafts to accommodate their needs while not paying attention to
impact 

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

[Petr Špaček]

On 4.4.2018 07:12, Geoff Huston wrote:
>>>
>>>
>>> All of the following conditions must be met to trigger special
>>> processing inside resolver code:
>>>
>>> o  The DNS response is DNSSEC validated
>>>
>>> o  The result of validation is “Secure”.
>>>
>>> o  The Checking Disabled (CD) bit in the query is not set.
>>>
>>> o  The QTYPE is either A or  (Query Type value 1 or 28).
>>>
>>> o  The OPCODE is QUERY.
>>>
>>> o  The leftmost label of the original QNAME (the name sent in the
>>>   Question Section in the original query) is either "root-key-
>>>   sentinel-is-ta-" or "root-key-sentinel-not-ta-”.
>>>
>>>
>>> Geoff
>>
>> I think that is the way to go.
>>
> 
> Mark, thanks for your patience with my evident cluelessness!

The list of preconditions above is exactly what I meant but did not
manage to explain why it is necessary. Thank you very much for hashing
it out.

My apologies to dnsop and especially Geoff and Paul, I started this
avalanche and then did not follow up. Mea culpa!

-- 
Petr Špaček  @  CZ.NIC

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