Subject: IETF-64 DNSEXT draft minutes

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 08 Nov 2005 19:41:36 -0500

Thanks to Wes Griffin for turning the minutes around in record time.

Draft minutes attached and available on-line:
http://onsite.ietf.org/proceedings/05nov/minutes/dnsext.txt

	Please send in comments or corrections by Nov 24'th 2005

	Olafur

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Nov 2005 15:37:52 +0100

Ólafur Guðmundsson <[email-masked]> writes:

>     draft-ietf-dnsext-rfc2538bis-09.txt
>         In RFC-Editors queue.

Actually, it is still in the AD Followup state, see:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12720&rfc_flag=0

I e-mailed Margaret late October asking for the status of this, but
there was no reply.

I have no idea what's holding up the document now.

Thanks,
Simon

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 09 Nov 2005 17:47:32 +0000

Ólafur Guðmundsson wrote:
> NSEC3 Report and Discussion
>     There is an issue tracker available for NSEC3:
>         http://nsec3.nominum.org.uk/

I guess things to do with "name" in Latin are popular, but actually its
Nominet, and the URL is really:

http://dnssec.nominet.org.uk/nsec3

>     Issue 6: There is a potential DoS attack on resolvers.
>         Evil editoritative servers can select such a high number of iterations

typo: s/editoritative/authoritative/

>         that resolvers are overwhelmed. The proposal is to allow resolvers to
>         specify an upper limit for iterations that it will accept and if a
>         response has a higher number the resolver will treat is as bogus.
>         
>         Olafur Gudmundsson asked why we can't get rid of iterations and just
>         use the salt. Ben explained that the iterations are designed to
>         increase the cost of a dictionary attack, while the salt is used to
>         increase the cost of a pre-computed dictionary attack. Olafur
>         rephrased his question to is the salt sufficient for the threats
>         people are seeing? Ben feels this is no, as a single iteration is
>         very easy to handle with a network probe.

This is garbled: my point was that it is a requirement to make
enumeration "as hard" in DNSSEC as it is in DNS. It is clear that this
is not 100% meaningful, since the mechanisms are different, but NSEC3 at
least means they both need a dictionary attack - in order to make the
dictionary attack "as hard" then we need a knob we can turn to adjust
the cost of computing whether a name is a match for a hash
(corresponding to the effort required to send a query in DNS).
Iterations is that knob.

>         Mike St.Johns said that if a number is going to be chosen, please put
>         it in the draft and be nice to implementors and users, don't make it
>         configurable, just set it across the board. Ben says if the working
>         group feels strongly about this it will be done.

I would still argue that it should be configurable, but I'm OK with the
draft stating a sensible default.

> Trust Anchor Management Reports and Discussion
>     This space is rapidly growing with drafts and there has been very little
>     review by non-involved participants. The chairs urge the working group to
>     pay attention because this item is very important to deployment.
>     
>     Current Work:
>     
>     draft-ietf-dnsext-trustupdate-threshold-01.txt
>         A co-editor stated that this update was primarily to boilerplate to
>         refresh the draft so that it would be available for consideration.
>         A prototype implementation is currently being worked on. This and the
>         following 2 drafts have IPR claims on file with the IETF. The
>         co-editor stated that he's been working with his university lawyer
>         and can proceed on a prototype implementation. He expects it will be
>         ready by the end of the year and will make it available to a select
>         group of people who will not be affected by the IPR.
>     
>     draft-ietf-dnsext-trustupdate-timers-01.txt
>         The editor said this version is almost a boilerplate change to
>         refresh the document. He has started an implementation in dnsjava.
>     
>     draft-moreau-dnsext-takrem-dns-00.txt
>     draft-moreau-dnsext-sdda-rr-00.txt
>         The author presented slides on some basics of trust anchor management
>         including some discussion of requirements and how the TAKREM proposal
>         works.
>         
>         Ben Laurie asked why, since emergency key rollover doesn't depend

_does_ depend on revocation

>         on key revocation and there will be some other mechanism to do
>         revocation, why not just use that?

>     draft-laurie-dnssec-key-distribution-00.txt
>         The author said the original idea behind this proposal was to do it
>         with x.509, but that x.509 has some issues with cross-signing and so
>         a future version will use PGP signatures. This is the only proposal
>         on the table that has no known IPR issues.
>         
>         Bill Manning asked about what transport this will use, as the user
>         is expected to visit a URL and follow a signature chain. His concern
>         is that the end-to-end assumption is increasingly wrong. Also, how
>         does the proposal cope when data can't be pulled from the URL? The
>         editor responded that http is the current transport, but really
>         anything can be used. Also, the data can be pulled from any location
>         so this shouldn't be an issue.

I also think its kinda weird to have to deal with "the Internet doesn't
work like its sposed to" in this draft - is Bill proposing that we also
rework, say, HTTP, to fix this problem?

>         Russ Housley asked why this is solving the problem, as he thinks it
>         doesn't.

I obviously blanked at this point, because I have no idea what Russ'
problem was - it would be good to get a statement from him on this.

>         Also, this looks exactly like what x.509 was designed to do.
>         The author said that x.509 doesn't support multiple certificates with
>         the same DN, Russ said it did.

I will be clarifying this with Russ later today.

>         Michael Richardson asked if there could be some sort of cross
>         signature threshold mechanism added so that resolvers only trust
>         what's going on when there are a minimum number of signatures.
>         The author said that this proposal was such that if a resolver
>         trusts a zone, then it trusts what the zone signs (and cross-signs).

I should also note that (as I understand it) introducing thresholds
would introduce IPR issues.

Cheers,

Ben.

---

From: Mike StJohns <[email-masked]>
Date: Wed, 09 Nov 2005 13:26:15 -0500

>draft stating a sensible default.

Slight clarification.  What I meant was that the implementers didn't 
get to pick the max, not that the zone operators couldn't select 
something smaller.  Pick one value, put it in the document and have 
all the implementers use it.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Nov 2005 03:11:38 +0000

> problem was - it would be good to get a statement from him on this.

OK, I've had this explained, and it was basically that I didn't say how
I planned to convert initial key setup into key rollover. I now know how
to do that, and it'll all become clear in the next version of the draft.

---

From: [email-masked]
Date: Wed, 9 Nov 2005 17:20:03 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> http://dnssec.nominet.org.uk/nsec3

This will actually end up at: http://nsec3.nominet.org.uk/

Geoff