Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt
Thanks Paul, and double thanks to Matthijs for his diligence in wisely forcing this. The new version is minor, but significant. I don't feel that it needs a new WGLC, but I want to put the diff between the two versions here so folks may take a second look. https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintai n-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt I'm going back over all the emails I have during the IETF LC process, just to make sure everything has been addressed. However, I think it's ready to move forward thanks tim On Tue, Jan 10, 2017 at 7:02 PM, Paul Wouters wrote: > On Tue, 10 Jan 2017, Paul Wouters wrote: > > Ohh, I think Matthijs actually found a bug: >> > > Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs > for being so persistent in bringing this up. My apologies that > I did not understand your concern before. > > Chairs, it is up to you to decide on redoing a LC on this or not. > > The diff between 04 and 06 that contains all changes since IETF LC: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintai > n-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt > > > Paul > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt
On Tue, 10 Jan 2017, Paul Wouters wrote: Ohh, I think Matthijs actually found a bug: Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs for being so persistent in bringing this up. My apologies that I did not understand your concern before. Chairs, it is up to you to decide on redoing a LC on this or not. The diff between 04 and 06 that contains all changes since IETF LC: https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06.txt&url1=draft-ietf-dnsop-maintain-ds-04.txt Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-06.txt
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 of the IETF.
Title : Managing DS records from parent via CDS/CDNSKEY
Authors : Olafur Gudmundsson
Paul Wouters
Filename: draft-ietf-dnsop-maintain-ds-06.txt
Pages : 10
Date: 2017-01-10
Abstract:
RFC7344 specifies how DNS trust can be maintained across key
rollovers in-band between parent and child. This document elevates
RFC7344 from informational to standards track and adds a standard
track method for initial trust setup and removal of secure entry
point.
Changing a domain's DNSSEC status can be a complicated matter
involving multiple unrelated parties. Some of these parties, such as
the DNS operator, might not even be known by all the organizations
involved. The inability to disable DNSSEC via in-band signaling is
seen as a problem or liability that prevents some DNSSEC adoption at
large scale. This document adds a method for in-band signaling of
these DNSSEC status changes.
This document describes reasonable policies to ease deployment of the
initial acceptance of new secure entry points (DS records)
It is preferable that operators collaborate on the transfer or move
of a domain. The best method is to perform a Key Signing Key ("KSK")
plus Zone Signing Key ("ZSK") rollover. If that is not possible, the
method using an unsigned intermediate state described in this
document can be used to move the domain between two parties. This
leaves the domain temporarily unsigned and vulnerable to DNS
spoofing, but that is preferred over the alternative of validation
failures due to a mismatched DS and DNSKEY record.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-06
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06
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
[DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-05.txt
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 of the IETF.
Title : Managing DS records from parent via CDS/CDNSKEY
Authors : Olafur Gudmundsson
Paul Wouters
Filename: draft-ietf-dnsop-maintain-ds-05.txt
Pages : 10
Date: 2017-01-10
Abstract:
RFC7344 specifies how DNS trust can be maintained across key
rollovers in-band between parent and child. This document elevates
RFC7344 from informational to standards track and adds a standard
track method for initial trust setup and removal of secure entry
point.
Changing a domain's DNSSEC status can be a complicated matter
involving multiple unrelated parties. Some of these parties, such as
the DNS operator, might not even be known by all the organizations
involved. The inability to disable DNSSEC via in-band signaling is
seen as a problem or liability that prevents some DNSSEC adoption at
large scale. This document adds a method for in-band signaling of
these DNSSEC status changes.
This document describes reasonable policies to ease deployment of the
initial acceptance of new secure entry points (DS records)
It is preferable that operators collaborate on the transfer or move
of a domain. The best method is to perform a Key Signing Key ("KSK")
plus Zone Signing Key ("ZSK") rollover. If that is not possible, the
method using an unsigned intermediate state described in this
document can be used to move the domain between two parties. This
leaves the domain temporarily unsigned and vulnerable to DNS
spoofing, but that is preferred over the alternative of validation
failures due to a mismatched DS and DNSKEY record.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-05
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-05
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] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt
Yes I agree, Push a new version if Tim agrees ? Olafur On Tue, Jan 10, 2017 at 12:53 PM, Paul Wouters wrote: > On Tue, 10 Jan 2017, Matthijs Mekking wrote: > > I personally think the simplification of using all zero's is good. If >>> someone accidentally changes the wrong number in the DS record when >>> changing parameters, it will prevent a mistaken delete request. While, >>> the zone might still fail, at least it won't be forced to go through a >>> period of insecure while the parental DS gets repopulated. >>> >> >> I am fine with using all zero's. I just don't think the change in >> resource record format is a good idea, dropping the last RDATA field >> from the CDS record. >> > > Ohh, I think Matthijs actually found a bug: > > The CDS RDATA is identical to the DS RDATA format, which is > according to RFC 4034: > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Key Tag | Algorithm| Digest Type | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >/ / >/Digest / >/ / >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The draft states: > > The keying material payload is represented by a single 0. > > So the CDS delete entry currently specified as: > >CDS 0 0 0 > > Should in fact be: > >CDS 0 0 0 0 > > > And similarly, the CDNSKEY is currently specified as: > >CDNSKEY 0 3 0 > > and should be: > >CDNSKEY 0 3 0 0 > > > Olafur, do you agree? Should we push a new draft version with this fix? > > > Paul > > ___ > 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] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt
On Tue, 10 Jan 2017, Matthijs Mekking wrote: I personally think the simplification of using all zero's is good. If someone accidentally changes the wrong number in the DS record when changing parameters, it will prevent a mistaken delete request. While, the zone might still fail, at least it won't be forced to go through a period of insecure while the parental DS gets repopulated. I am fine with using all zero's. I just don't think the change in resource record format is a good idea, dropping the last RDATA field from the CDS record. Ohh, I think Matthijs actually found a bug: The CDS RDATA is identical to the DS RDATA format, which is according to RFC 4034: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm| Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / /Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft states: The keying material payload is represented by a single 0. So the CDS delete entry currently specified as: CDS 0 0 0 Should in fact be: CDS 0 0 0 0 And similarly, the CDNSKEY is currently specified as: CDNSKEY 0 3 0 and should be: CDNSKEY 0 3 0 0 Olafur, do you agree? Should we push a new draft version with this fix? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt
On 10-01-17 17:50, Paul Wouters wrote: > On Tue, 10 Jan 2017, Matthijs Mekking wrote: > >> I see that IESG has approved this document, but I am still wondering >> this: >> >> On 01-12-16 13:20, Matthijs Mekking wrote: >>> Hi, >>> >>> I read this again. I still wonder if in the case of DNSSEC Delete >>> Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is >>> 0, the Digest/Public Key MUST be ignored. >>> >>> This way, you don't have to change the CDS/CDNSKEY format defined in >>> RFC >>> 7344, most likely causing less problems with deployed software. > > I personally think the simplification of using all zero's is good. If > someone accidentally changes the wrong number in the DS record when > changing parameters, it will prevent a mistaken delete request. While, > the zone might still fail, at least it won't be forced to go through a > period of insecure while the parental DS gets repopulated. I am fine with using all zero's. I just don't think the change in resource record format is a good idea, dropping the last RDATA field from the CDS record. Matthijs > > Paul > > ___ > 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] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt
On Tue, 10 Jan 2017, Matthijs Mekking wrote: I see that IESG has approved this document, but I am still wondering this: On 01-12-16 13:20, Matthijs Mekking wrote: Hi, I read this again. I still wonder if in the case of DNSSEC Delete Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is 0, the Digest/Public Key MUST be ignored. This way, you don't have to change the CDS/CDNSKEY format defined in RFC 7344, most likely causing less problems with deployed software. I personally think the simplification of using all zero's is good. If someone accidentally changes the wrong number in the DS record when changing parameters, it will prevent a mistaken delete request. While, the zone might still fail, at least it won't be forced to go through a period of insecure while the parental DS gets repopulated. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
Moin! On 7 Jan 2017, at 23:54, Scott Schmit wrote: why you think hostile actors will do things with RPZ that they couldn't do now? > > For the very reasons that the authors want to make this an RFC -- RPZ > isn't interoperable between DNS resolvers today. Once this RFC is > published, it's clearly hoped that RPZ will be more interoperable and > thus widespread. > > It's true that countries can legislate anything they want, and the > publication (or not) of an RFC won't change that. > > But the enforcement of laws costs resources, and resources are finite -- > so a country passing laws requiring network operators to filter and/or > redirect will have no choice but to prioritize enforcement of such laws > against other needs. I don't know if you ever where involved in law creation, but I can assure you, being involved in lobbying lawmakers to make sensible laws and also implementing redirection via DNS which is common in a lot of countries, that lawmakers give a damn about how much it costs providers to implement the redirection. When implementing redirection via DNS I've seen every sort of possible input thrown at me from snail mail to EBDIC text files, pdf, you name it. The funniest case was one country that had different branches of the government issuing block lists one with a word document over ftp and the other with XML over https. I would love to have had a common format then and not re-invent the wheel on every new case. BTW all of these implementations where in what one would consider democratic countries in Europe (The nice thing about the EU is even if you have a EU directive you still get 27 different laws to follow if you are a pan european provider ;-). My point here is if you don't like redirection and blocking via DNS (which IMHO is much better than mandating DPI - unless you are a DPI vendor ;-) get involved in politics and try to change that at OSI layer 9. None of the stuff we discuss here will change any law or mandated redirection, nor will it change the efforts of lots of sysadmins and security researchers using the discussed technology to block bonnets and bad guys to not infect subscribers. It just would be nice if these poor sysadmins had some common tools, but as said we've solved problems without that until now and as others said RPZ actually might not be the best tool to express DNS policy configuration, but given the current state of the discussion I have serious doubt that the working group would consider working on that at all. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
>> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathro >w > >>4) DNS is not really private so Google may offer their DNS services over HTTP >S >> 5) Governments may force Google to block popular sites, so users switch to >>other DNS resolvers, again over HTTPS. > >See https://developers.google.com/speed/public-dns/docs/dns-over-https >but I don't know how clients bootstrap that API without classic DNS. The nice this about Google is that they are too big to block. It is not a problem to use plaintext DNS to connect to Google because the CA system and possibly DANE will protect the TLS connection. >block child porn, drug, terrorist, and malware web pages as well as >attempts by corrupted laptops and smart phones to bypass blocks on >port 53 and reach evil or merely unfiltered DNS/HTTPS servers including >those run by Google? I'm not sure what 'HTTPS proxy' means in this context. If a public wifi at an airport can decode TLS traffic then we have a serious security hole. (Of course SNI is a problem. Hopefully TLS 1.3 will improve that) But the bigger problem is that most users don't really care about the difference between a public wifi operated by an airport and a public wifi operated by a criminal. And maybe the criminal just took over the wifi router at a respectable restaurant. So an ISP can null route traffic to known bad destinations (though people may switch to TOR to even deny an ISP even that option) but anything that goes beyond that (ISP access to DNS, etc) also provides great opportunities to attackers. It doesn't really help much if an airport blocks malware but the bar next door doesn't. So for any mobile device, you have to secure the device anyhow. Then this extra protection by ISP mostly becomes another attack vector. So at least for mobile devices it makes sense to make sure that all traffic on the wifi interface is encrypted and we keep the ISP out of the loop as much as possible. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
