Tim Wicinski | 17 Apr 00:58 2014
Picon

Final shepherding comments for draft-ietf-dnsop-delegation-trust-maintainance-10


https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

All

Please take a look at version -10 of this draft. I believe that the 
authors have addressed all the issues that were raised during the very 
comment period.

I believe that draft-ietf-dnsop-delegation-trust-maintainance-10 has 
reach working group consensus.  I urge folks to give it one last look 
and if there is anything you wish to raise, please raise directly, 
otherwise silence is agreement.

I want to thank all the individuals who contributed comments and feedback.

tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 16 Apr 18:32 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-10.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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-10.txt
	Pages           : 20
	Date            : 2014-04-16

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-10

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

internet-drafts | 16 Apr 14:03 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-09.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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-09.txt
	Pages           : 20
	Date            : 2014-04-16

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-09

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

internet-drafts | 15 Apr 22:28 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-08.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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-08.txt
	Pages           : 20
	Date            : 2014-04-15

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-08

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

Mark Andrews | 15 Apr 07:57 2014

EDNS version 1


	http://www.ietf.org/id/draft-andrews-edns1-00.txt

--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 14 Apr 22:44 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-07.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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-07.txt
	Pages           : 20
	Date            : 2014-04-14

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-07

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

Daniel Migault | 14 Apr 21:41 2014
Picon

draft-mglt-dnsop-search-list-processing-00.txt

Hi folks,

Please find draft-mglt-dnsop-search-list-processing-00.txt [1]  This draft comes in the context of generic TLD with possible naming collision. In order to keep naming resolution stable and reliable, it describes 1) how resolver should generate their search list, 2) how resolver should  distinguish a name resolution that needs to be associated with a search list and 3) how a resolver should perform a resolution involving search list.

Feel free to comment/review.

BR,
Daniel

[1] http://tools.ietf.org/html/draft-mglt-dnsop-search-list-processing-00

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-drafts | 14 Apr 18:09 2014
Picon

I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-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 Working Group of the IETF.

        Title           : Automating DNSSEC Delegation Trust Maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-06.txt
	Pages           : 19
	Date            : 2014-04-14

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Edward Lewis | 14 Apr 16:06 2014
Picon
Picon

Re: Spinning out of scope on draft-...-delegation-trust...

In the world of trade-offs:

Having one record:

1) Can retrieve it in one query
2) Easier to specify what to publish and what to read
3) Parsing involved inspection of RDATA

Having two records:

1) Need two queries or rely on ANY
2) Have to explain to the client what to publish, server has to deal with inconsistencies
3) Parsing reuses existing code

I invite more trade-offs to be added.

The parsing should not be in the DNS client or server, that would be buried in the client key manager and the
parent provisioning systems.  Each of those have to add and check a that there’s a other-wise valid
signature corresponding to a key with a SEP bit set, so, they have some rewriting to do anyway.

There’s no reason that a RFC 1034-style DNS server and client need to read these records.  They are not used
by the name server.  By RFC-1034 style I am excluding DNS servers that have on-line key management built in
(such as ISC’s BIND 9.7 and on - don’t quote me on version numbers, it may have been earlier).

I don’t see why the RDATA presentation can’t just be a hex sequence (or Base64)….so long as the end
points can read and write it.

Come to think of it - we can use the TXT record for maximum flexibility! ;)

Looking at these tradeoffs, I see the expense of trying to specify and explain to operators - via the tools
they use - of why there are two records and what happens if they aren’t the same as far more costly than
having the name server need to deal with varying formats.  Yes, I know that NAPTR is also a poor example, in
fact, there aren’t too many examples of varying record formats out there - except of course for TXT. 
(Hmmm, perhaps that is one reason why it is so popular.  I mean, besides the firewall pass through and other
acceptance “features.")

On Apr 14, 2014, at 9:16, Matthijs Mekking <matthijs <at> nlnetlabs.nl> wrote:

> On 04/14/2014 03:05 PM, Edward Lewis wrote:
>> I think it is silly to burn two RR types to communicate the same
>> thing.  You’re inviting debate on testing and handling the two being
>> out of sync.
> 
> Would you prefer one RR type with varying RDATA format (like with
> IPSECKEY)? I don't.
> 
> Best regards,
>  Matthijs
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Tim Wicinski | 14 Apr 15:54 2014
Picon

Final revision of the charter

All,

The bulk of the comments in the last round where in regards to the poorly worded Item 6 on 'Special Names'.  With the assisting of Andrew Sullivan, we've replaced the wording of that one to be more focused on the outcome and not the process, and removed those words like 'liason'.

Additionally, I replaced the sentence in Item 1 listing the type of resolvers but failing to mention stub resolvers, per comments from Petr and Andrew, et. al.

Also, in a fit of editorial obsession, I ran 'fmt' over the whole document, so if you're


We feel this has reached a 'rough consensus' and our Wonderful AD will present this to the IESG to begin that process.

Thanks everyone for your comments and opinions.

tim

-------

The DNS Operations Working Group will develop guidelines for the operation of DNS software and services and for the administration of DNS zones. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, TLD name servers, or any other resolver or server functioning as part of the global DNS. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software and services, including root, TLD, and recursive servers. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning DNS operational procedures in IPv6 and mixed IPv6-IPv4 networks, and provide documentation and guidance on DNS-related IPv6 transition and coexistence issues. 4. Publish documents on extensions or protocol maintenance to the DNS Protocol, with a focus on the operational impacts of such changes. Act as clearinghouse for discussion or provide advice to ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a clearinghouse for DNS-related issues where people can bring drafts that document the problem space around these issues. The group will then decide whether these issues belong in DNSOP and, if not, will work with the authors and appropriate ADs to determine the appropriate group for the work. 6. Publish documents that attempt to better define the overlapping area among the public DNS root, DNS-like names as used in local or restricted naming scopes, and the 'special names' registry that IETF manages, perhaps including how they might interact. This work must take into consideration issues that are strictly beyond the operation of the DNS itself, and the working group will consult with IETF liaisons to other organizations as appropriate.
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Edward Lewis | 14 Apr 15:05 2014
Picon
Picon

Spinning out of scope on draft-...-delegation-trust...

Perhaps again I’ll be labelled as a potential troll for this.  Again, using an example for a non-specific comment...

On Apr 14, 2014, at 7:09, one person wrote:

> At 10-04-14 21:54, someone else:
> 
>> We already have too many parents that have I do not know how many
>> stupid rules for ...
> 
> While I agree with you some (TLD) parents are sometimes too pedantic,

It is not in scope for the WG to judge the requirements which various DNS registries (TLD and otherwise) have
signed up to meet.  It would be far more constructive to accept actual, demonstrated needs than such for a
tech-utopia.  One of the things I learned when comparing DNSSEC operations to protocol engineering was
that operators face a wide range of environments.  If the IETF is to produce protocols that are universally
appealing, then the protocol has to pander - or be so good that it results in “simplifying” the number
of different environments.  The IETF desires greater operator involvement, you don’t get that by
complaining about the operators’ use cases.

Process-wise I’m surprised to see a new version come out before the end of the last call.  There was a draft a
few years ago that I was following.  Each time I’d redline half a copy I’d learn that the one I was reading
had been replaced by the next.  That wasn’t a last call time, so it was annoying.  But this time there is a
last call and I would think the editors should wait for any stragglers.  (This time I did respond earlier.)

The rest of this I may have said before.  This draft (the CDS/CDNSKEY) describes an interchange from
essential the key manager of the child zone and the provisioning system of the parent zone.  The
communications medium is one direction, no feedback possible, but the client (in the sense that one end
takes the initiative) can detect changes made by the server.

This is like (analogy time) one person who can speak to another and see the result, but there’s no other
communication path. (Unrelated, this also applies to praying.)  Staying in-band only, the only way to
make this work is to involve relative time (time-outs).

I do not to intend to say this is dead when I say: this cannot scale (unquantifed).  I mean that, in the sense we
give up on scaling, we can define a protocol.

I think it is silly to burn two RR types to communicate the same thing.  You’re inviting debate on testing
and handling the two being out of sync.

I don’t have a problem with leaving the records in as long as the parent is supposed to have the record
represented in its zone - but only because I’m willing to sacrifice scaling.  This causes less state to be
maintained (but is does create a greater load on a parent system that is polling).

I think that all use of the communications medium has to adhere to the basic rules of security.    Here that
being ZSK signed - knowing that the validation engine does not inspect the SEP bit - but that when
considering this is a client key manager to parent provisioning protocol (not DNS), the extra signature
should be there.  (Come to think of it, the ZSK RRSIG is a redundant, but don’t expect cache-protecting
validators to respect the SEP bit.)

Please take steps to simplify the protocol and discussion.  Giving up on scaling can make this a tool that
some operators can use - and perhaps on a small scale within an organization.  It would be interesting to see
is a general purpose DNS implementation will try this to manage a set of zones (as opposed to managing zones
in isolation).

DNSSEC is clumsy.  It needs a solution here.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Gmane