[DNSOP] Minutes of IETF-77 DNSOP WG

[Stephen Morris <[e-mail]>]

Colleagues

Here are the minutes of the last Working Group meeting at IETF-77, Anaheim. Apologies for the delay.

Regards

Stephen




-----------------------------------------------------------------------------
WG:        DNS Operations (dnsop)
Meeting:   IETF 77, Anaheim
Location:  Anaheim Hilton, "California A"
Date:      Wednesday, 24 March 2010
Time:      13:00 - 15:00 (UTC-7)
Chairs:    Peter Koch     <[e-mail]> <[e-mail]>
           Stephen Morris <[e-mail]>
Jabber:    xmpp:[e-mail]
WG URL:    http://tools.ietf.org/wg/dnsop/
Agenda:    http://www.ietf.org/proceedings/10mar/agenda/dnsop.txt
Material:  https://datatracker.ietf.org/meeting/77/materials.html
-----------------------------------------------------------------------------

1) Administrivia
[chairs][5 min][13:00]
<http://www.ietf.org/proceedings/10mar/slides/dnsop-0.pdf>

 - minutes scribe  Rob Austein
 - jabber scribe   Wes Hardaker

Stephen was introduced as the new co-chair.


2) Status Update
[chairs][5 min][13:05]
Status has been sent to the mailing list 
(http://www.ietf.org/mail-archive/web/dnsop/current/msg08292.html).

Two documents (draft-ietf-dnsop-as112-ops.txt and 
draft-ietf-dnsop-as112-under-attack-help-help.txt) have references to the local 
zones draft (draft-ietf-dnsop-default-local-zones.txt); the latter may require 
updating.


3) Active Drafts

3.1) DNSSEC Signing Policy & Practice Statement Framework
draft-ietf-dnsop-dnssec-dps-framework-01.txt
<http://www.ietf.org/proceedings/10mar/slides/dnsop-1.pdf>
[Fredrik Ljunggren][10 min][13:10]

Very few comments so far, only minor updates. .SE have revised their DPS, which 
has been published (https://www.iis.se/dl/DPS-PA9-ENG.pdf) under a creative 
commons license.

Peter Koch: 3-5 people other than authors have read current version, need more 
readers.  

3.2) DNSSEC Trust Anchor History Service
draft-ietf-dnsop-dnssec-trust-history-01.txt
<http://www.ietf.org/proceedings/10mar/slides/dnsop-2.pdf>
[Olaf Kolkman][10 min][13:20]

Wouter Wijngaard's document was presented by Olaf Kolkman.

The goal is an easy way to update a key set when the it has expired by 
following a plausible chain of records and signatures from your old state to 
the current state.  It proposes a new TALINK RR (type 58).

The current draft documents security policy choices.  It encourages use of RFC 
5011, provides alternatives for cases where that is not practical, and should 
warn operators if changing keys.

The authors think the document needs another revision, mostly for stylistic 
issues, after which it is hoped that it will be ready for WGLC.

About ten people have read the document.

Jakob Scklyter: Wants to know if there are implementations.
- Olaf Kolkman: We are aware of one implementation.

Andrew Sullivan: Thinks it is not yet close to WGLC; as well as stylistic 
issues he also wants clarifying text on a few issues.
- Olaf Kolkman: There may still be a roll-over-and-die issue in the document; we 
need to be careful about query load given all the things one might need to 
check.

Peter Koch: Concerned that there may not be many use cases if the world really 
does go to single root trust anchor. 
- Olaf Kolkman: Part of the point here is supporting machines that stay shut 
off for periods of time on a regular basis; also, enterprises might have local 
trust anchors for internal use.
- Olafur Gudmunsson: Worry about installing from old DVD, not just machine on 
shelf.
- [missed name]: This has applications even if most of world uses single trust 
anchor.

3.3) DNSSEC Operational Practices, Version 2
draft-ietf-dnsop-rfc4641bis-02.txt
<http://www.ietf.org/proceedings/10mar/slides/dnsop-3.pdf>
[Olaf Kolkman][30 min][13:30]

Since the last version, have resolved issues on HSMs, NSEC-NSEC3 
considerations.  Open issue (typecodes) for RSASHA256. Scott Rose (NIST) has 
reviewed the NIST material in the draft.

Many issues addressed (all believed resolved) on ZSK rollover frequency, flawed 
cryptography, timescales, and assumptions surrounding rollover; section 3 has 
been rewritten to stress operational considerations as driver for (rather than 
result of) crypto parameters; it needs review.

Andrew Sullivan: The language not yet cleaned up enough, it still assumes 
frequent rollovers in places.  Substance OK, just cleanup. 
- Olaf Kolkman: Yep, see "needs review".

Jelte Jansen (via Jabber Scribe): Don't consider key algorithm rollover
resolved in current text.
- Olaf Kolkman: Please send more details to the list.

Olaf Kolkman: Added section 4.4.5.2 about non-cooperating DNS operators. This 
is mis-named, as it is really about how you prevent vendor lock-in when an 
operator holds a victim's private keys.  The issue is considered closed other 
than needing review of the figure.
- [Missed name]: Non-cooperative case not solvable, what I'm looking for is 
guidance on how to move zone in cooperative case.
- Olaf Kolkman: Thinks this is covered, please take to list.

Peter Koch: Five people have reviewed this operator text but none are 
operators.  The document needs more reviewers.

Olaf Kolkman: The status of the document (currently set at BCP) is to be 
addressed later.   This is a living document; at this point, we're working on 
version 2, we expect at least a version 3.  We're trying to close off issues so 
it is currently not ready for WGLC.

Roy Arends: Lots of people (~50) attended DNSEXT and saw discussion of "roll 
over and die".  That relates to this document in KSK rollover frequency.  Roy 
will send his concerns to DNSOP mailing list.

Olaf Kolkman: Wants review of section 3, particularly 3.1.2.1, the distinction 
between KSK that is or is not a trust anchor, plea for conservatism when 
rolling trust anchors.  The document still advises exercising the process on 
regular basis.
- Geoff Huston: Argue that we should roll over early and often is like 
advising that we should crash cars early and often to build better cars. Geoff 
does not buy the argument that crashing early and often produces a better 
product.
- Olaf Kolkman: Need more research, but what we found in "roll over and die"  
was a broken implementation.  A better analogy would be testing a standby 
generator.
- Roy Arends: It would be more productive if the document had more granularity 
(detail?) on reasons for doing rollover.  It also should separate the view from 
the authoritative server from the view from the validator.  Will send text.
- Sam Weiler: Geoff's analogy is wrong, Olaf's is right.  You test brakes to 
find out if they fall off the car.
- Ed Lewis: Rolling  a key is a normal operation.  You want to roll keys to 
protect from other operational things, e.g. people leaving the data center, etc.
- Olaf Kolkman: The big elephant in room is the root.  If we don't roll it 
until something bad happens, that will probably be too late to find out whether 
rolling works.   Shipping static data in distribution was a mistake;  now we 
know, industry is aware.
- Andrew Sullivan: The document is not entitled "key management for the root 
zone", it is a general purpose document.  It would be serious mistake to put 
bunch of rules in to solve one zone's (root's) problem that had to apply to
every zone.  Don't think recommending regular rollover for non-root zones is a 
good idea; it might be a bad idea.  The current draft is slanted towards large 
infrastructure zones.
- Olaf Kolkman: Fair enough, the question is where to draw the line.  We want 
considerations clear enough that document readers will understand that choices 
are different.
- Rob Austein: Glad we tested early so we found ROAD problem while the 
population was still small.   This is not the last bug we will ever find in 
DNSSEC, let's please find them early.
- Jim Galvin: Need to distinguish two circumstances: what we do in beginning vs 
what we do steady state.  [Missed a couple of sentences] And yes, auto 
manufacturers do crash cars to test them.   Some people will want to exercise 
process, some will prefer stability.
Matt Pounsett: Don't want specific recommendations for root.  Options that 
don't get exercised don't get maintained; does not necessarily need to be in 
production, can be in lab, but hard to simulate all of it in lab, particularly
parts that are inter-organization.   They do need to be  necessarily frequent,
but regular rollovers are necessary so people will remember what to do.

George Michaelson: Doesn't think document is quite right choosing key lengths.  
The justification is missing and real cryptographers hedge when asked these 
questions.  This goes to rollover, why do we have to withdraw old key?
- Olaf Kolkman: Agree on answers we get from cryptographers; tried to follow 
approach of "what are our needs?" and derive key length from that.
- George Michaelson: Have we ever lived through serious trust anchor compromise 
in any commercial PKI? We have not practiced this stuff anywhere.
- Olaf Kolkman: There is no way to change PKI certificate stores in practice, 
this is a different game.

Joao Damas: If we hadn't done rollovers, the "roll over and die" problem would 
not have occurred.  Want recommendation: if your parent is not signed, don't 
just go with static trust anchor, use RFC 5011 or DLV.
- Joe Abley: Scheduled and emergency key rollovers are very different things.  
In an emergency you don't have time to use normal procedures.  There are enough 
differences that scheduled is not really practice for emergency, so don't 
justify scheduled as practice for emergency.
Olaf Kolkman: RFC 4641 strongly recommended separating ZSK and KSK issues, 
wants help from chairs here: is assumption that you need to introduce new
key material a prerequisite for DNSSEC, and do you need practice rollover as a 
consequence?  Previous assumption was "yes", if answer has changed, please tell 
the document author or, better, volunteer to write a different document.
- Peter Koch: This is postponed to list.  Clearly we can't keep changing 
assumptions out from under document in progress.


4) Other (non WG) Internet-Drafts

4.1) DNSSEC Key Timing Considerations
draft-morris-dnsop-dnssec-key-timing-02.txt
<http://www.ietf.org/proceedings/10mar/slides/dnsop-4.pdf>
[Johan Ihren][10 min][13:55]

Very close to becoming WG doc, but it is still independent.   Both KSK and ZSK 
rollover fully treated, and the draft is now more neutral on alternatives.  We 
were asked to cover all rollover mechanisms, so did.  Unclear on whether should 
cover algorithm rollover, document does mention it but not as fully as key 
rollover.  This topic may warrant a separate document; we don't have enough 
experience with algorithm rollover yet to write much about it.

Does WG want to adopt this?

10 have read latest, 15-20 have read some version.   

Authors of this and 4641bis agree that this doc should be separate from 4641bis.

~25 in favor of adoption, no objections, need to confirm on list but
assume it is now a WG document.  Unless the list says otherwise, it remains 
separate from 4641bis.

4.2) Reverse DNS in IPv6 for Internet Service Providers
draft-howard-isp-ip6rdns-03.txt
<http://www.ietf.org/proceedings/10mar/slides/dnsop-5.pdf>
[Lee Howard][10 min][14:05]

ISPs pre-populate reverse zone in IPv4 but can't in IPv6.  This is an 
informational draft to document what options ISPs have and the considerations 
for each.

10-15 have read document.

David Hankins: does the text really say say need FQDN option to do DDNS?
'Cause that ain't so.  Maybe it's dependent on reconciliation of domain names?
- Lee Howard: will check.

Ted Lemon: This codifies existing broken practice without saying "don't do it 
that way".  Using PTR RRs for authentication is not secure, don't say it is.  - 
Peter Koch: So you want to make recommendations, not just considerations?  - 
Ted Lemon: I see the slippery slope.  Worried that people will see bad options 
listed without sufficient vitriol and go implement the bad things.

Andrew Sullivan: Still have tire marks from previous reverse tree documents.  
Don't make recommendations.  Can say "there are people who believe these 
things" and point to some other document expressing opinions on why you 
shouldn't believe these strange things.  We are not going to fix all the broken 
ideas in this space.   Real problem is don't understand what the problem is 
that we need to solve here.   Last time in this shark pool the document was 
watered down to say "reverse DNS exists" and even that was contentious.

Alain Durand: There is value in telling people that they don't have to 
pre-populate.  OK to say just that, plus boilerplate.   Operators think they 
need this permission.
- Ted Lemon: Agree with Alain.  Just say "you don't have to do this".  Why not 
only document cases we want people to do?
- Lee Howard: Can you define what cases we like?
- Peter Koch: Can we take this to the list?
- Lee Howard: -00 did say "you don't have to pre-populate".
- Peter Koch: Have heard "this is good work but what does it mean when a 
document like this comes out of the IETF?"  Is the IETF sanctioning sordid 
practices? What purpose should document solve?  Doesn't mean the document has 
to go away, but should be clear what statement the document is and is not 
making.
- Alain Durand: What's wrong with and IETF label on a document saying "you 
don't need to do a stupid thing?"
- Peter Koch: Nothing.  But if we adopt the document, it should be clear what 
intent of the document is.
- Alain Durand: To give guidance that operators do not need to do something bad.
- Peter Koch: A document that lists fifteen ways to shoot oneself in foot could 
be construed as advising shooting oneself in the foot.
- Alain Durand: Agree, remove all of that.
- Andrew Sullivan: Documenting all the stupid things one should not do in DNS is
a non-terminating task.

Chairs will discuss with Lee and make sure we're asking the right question.


5) Current & New Topics

5.1) NSEC3 Hash Performance
<http://www.ietf.org/proceedings/10mar/slides/dnsop-6.pdf>
[Matthijs Mekking][10 min][14:15]

Research question: what's worst case effect on validator of increasing the 
number of NSEC3 hash iterations?  The number is determined by the authoritative 
server but it has an effect on the validator.

The graphs shows that increasing key length has more significant effect on
validator rate than increasing iterations.  With short (1024 bit) keys the 
effect is significant (cuts Unbound rate by half) but with longer keys the 
effect becomes less significant.

Sam Weiler: Computation overhead is roughly square of key length, this does not 
show quite that, any ideas?
- Matthijs Mekking: Guesses, but not really. Key length has much less effect in 
an authoritative server (NSD) because NSD isn't signing on the fly.

Ed Lewis: What's doing key operations on the authoritative server?
- Matthijs Mekking: Hash computations answering questions about nonexistent 
domains.

5.2) IPv6 & recursive resolvers: How do we make the transition less painful? 
<http://www.ietf.org/proceedings/10mar/slides/dnsop-7.pdf>
[Igor Gashinsky][15 min][14:25]

At the moment, adding AAAA pointing to production services will break 0.078% of 
the users, which is about 470K users, which is bad.

Alain Durand: We have one source of this number, want better study on this as 
number may change our opinion on how real this is.
- Igor Gashinsky: Ask me again in June, we're studying it.

More than 4 second delay on connecting to www.whatever is considered broken in 
terms of customer experience. Broken here means "These people could reach me 
over IPv4, turning on AAAA RRs caused them not to be able to reach me anymore".

Jinmei Tatuya: What name was this AAAA problem tested with?
- Igor Gashinsky: Experimental name within .google.com.

A hack is don't give AAAA to customers you think will break if you do so.  
Specifically. if query comes in over IPv4, DNSSEC not being used, and an A RR 
exists, say there is no AAAA.

This is ugly.  May also be necessary.  Needs ACL mechanism to give
better control. Is this worth pursuing?  Should there be an informational RFC?

Warren Kumari: Aren't we stuck until everybody implements this?
- Igor Gashinsky: Can whitelist.
- Alain Durand: This is better than whitelisting.  The question is whether
price is worth it, can't answer without better data on real size of problem.
- Igor Gashinsky: Difficult to instrument to detect the problem, and 
instrumentation is not going to tell us where problem is coming from.
- Alain Durand: Right, all of these all we can tell is that something is
broken, so we make a change and hope it will improve matters.
- Igor Gashinsky: This is a hack, it's not a DNS problem, DNS is my sonic 
screwdriver.
- Ed Lewis: I have v6 on both ends here this week and still can't get
through.  This hack would not solve my problem.
- Igor Gashinsky: In your case the hack would not be interfering, you might 
still be broken, but it won't be me that's breaking you.

James Woodyatt: Testing for IPv6 connectivity via transport used for DNS is 
broken.  Might be recursive nameserver that has v6 but not the
end user.
- Igor Gashinsky: Right, this does not hold true for forwarders.  So
you'd have to implement this hack in forwarders too.
- [Missed name]: Solution is worse than problem, need data.
- Evan Hunt: it's "filter-AAAA".   Not quite in mainline BIND, ISC is not 
exactly in favor of this.
- John Brozowski: We don't love this, but it may be least bad option. We need 
to understand effects and alternatives.

Ted Lemon: You measured how many people would be broken by answering AAAA 
correctly.  You have not measured how many would be broken by this hack.   
You're adding complexity to solve a problem, that complexity will break other 
things.  Need to do cost/benefit.
- Igor Gashinsky: Absolutely.  Want to instrument something once we have a 
second source of data.


6) I/O with other WGs

draft-savolainen-mif-dns-server-selection-02.txt
Ran out of time.  WG please read.


7) A.O.B.

draft-wang-dns-newzone-notify-00.txt
Ran out of time.  Will address on list.