Re: IETF-64 DNSEXT draft minutes

[Ben Laurie <[e-mail]>]

Ó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.

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