RIPE 48

• content to the Chair of the working group.
• format to webmaster@ripe.net.

RIPE48 TechSec Working Group
Amsterdam, 5 May 2004, 9:00-10:30

Chair: Ted Lindgreen
Notes: Olaf Kolkman with help from Daniel Karrenberg and Scott Rose


Agenda

A. Administrative Matters

* scribe
* list of participants
* agenda
* minutes

B. Report from the Monday DNSSEC session
Steve Crocker (20 min)

C. Secure resolver developments at NLnet Labs
Jelte Jansen (10 min)

D. Resolver application interface
Miek Gieben (10 min)

E. Open discussion on secure resolvers and application/validator interaction
Bill Manning

F. AOB

----------------------------------------------------------------------
A. Administrative Matters


Ted Lindgreen (TL): Session is dedicated to DNSSEC.

TL: Based on Jan 2004 experiences the server side is done. We will focus
on deployment and validator/resolver issues.

* minutes
No remarks on the minutes


----------------------------------------------------------------------
B. Report from the Monday DNSSEC session
Steve Crocker (20 min)


Notes on the presentation, in addition to the slides.

SC: The DNSSEC spec is about to be done. Will the deployment happen easily?
The purpose is to identify the interdependencies and see where and
what work needs to be done.

SC identifies a number of deployment steps, and alternatively looks
at the phases of deployment.

A pair of meetings was organized one May 3 in Amsterdam and one in San
Francisco May 23.
Some of the topics discussed: key-management, anchor points,
end system procedure, training and privacy considerations.
These where presented in a series of talks that will be available from
[http://www.sdl.sri.com/other/dnssec].

Rough conclusions:

- Server side looks good but tricky for larger zones
- Privacy issues are not put to rest yet
- End systems will be the biggest headache
- Lot of operational details such as key distribution and rollover
schemes
- Training material and policy advice is crucial.

Next steps:

Meeting in San Francisco, and the formation of a 'steering group' that
build an maintains a roadmap



TL: When will the root will be signed.

SC: Don't know, one line of thinking says that technical hurdles
are taken and that signing can be done pretty soon, another line
is more careful and wants to move with large amounts of caution.

The effort is about identifying the FUD and to close the polemic
loops by documenting the issues.

It is clear that if the root were to be signed, deployment of DNSSEC
would be faster.


Patrick Falstrom (PAF): The IAB is responsible for some zones like
e164.arpa. What would your advice be if the request would come if a
zone is to be signed

SC: Signing is good, rather sooner than later. The order in which
things need to happen will need to be established.



Johan Ihren: While introducing new DNSSEC there are two
considerations: introduce security, and avoid breaking stuff. The
root is old, lots to break, e164.arpa is new, little legacy and
therefore an easier place to deploy.

TL: If the root is not signed, secure island will be popping up and
secure islands may endanger the common namespace.


Rudolf van der Berg (RvdB): once the technical issues are solved it
becomes a political issues, how do we get geographical spread
politicians to buy in?

SC: It is clear that this should not be a US centric, having the
meeting in Europe was in an effort to make this a global effort.

Only having technicians is not sufficient for deployment, one needs
vendors and registries buy in.

----------------------------------------------------------------------



C. Secure resolver developments at NLnet Labs
Jelte Jansen (10 min)


DNSSEC awareness in resolvers.

Notes on the presentation, in addition to the slides.

Jelte (JJ) describes the various manners in which a keys for
validation can be done top down or bottom up. He bases his design
on a top down approach.

This recursive top-down resolver is to be implemented in libc and
will only use authoritative servers.



OK: is this going to be wide spread? Since bypassing caches
is dangerous.

JJ: Essentially this will be proof of concept.

Sam Weiler (SW): How will you configure your trust-anchor.

JJ: It is preconfigured.

Bill Manning (BM): How long have you been working on this? Asked since
we have no idea when/if the root is signed.

SW: If you are assuming a signed root do you allow trusted anchors
lower in the tree?

JJ: Only one trusted anchor, at the root, is implemented currently.



----------------------------------------------------------------------

D. Resolver application interface Miek Gieben (10 min)



Notes on the presentation, in addition to the slides.

Miek describes in which states a validator can end up and explains
that there is a need for resolvers to pass validation data to the
applications. Miek proposes a method where error bit arrays are used
to indicate the error status.

draft-gieben-resolver-application-interface-00.txt


No questions.


----------------------------------------------------------------------
E. Open discussion on secure resolvers and application/validator interaction
Bill Manning


Notes on the presentation, in addition to the slides.
The presentation was intentionally interrupted by discussion
a few times.

Bill explains that we are still exploring this problem space and that
there is a shared view on what is needed. The common ground Bill
identifies is that one bit is not enough and that apps want to use
their local policies.

"Users/Apps" may want to have diagnostics and audit trails. Is our
idea on the set of classes of apps complete?


Leslie Daigle (LD): Concludes a small discussion in the room; we all
agree that information needs to be transfered to the application so
that local policy can be enforced.

Summary of discussion between SC - DFK: Although it is not clear users
care about this applications will need some default policy, or some
mechanism to set the policy for specific part of the network.

RvdB: The question is how much information is there in DNSSEC that we
can display to the user/application so that an informed choice can be made.

BM: There is a proposal on this information in Giebens draft.

In his presentation Bill presents his view that delegation and chain
validation are independent and may need to done at different times and
different places.


OK: Observes that BM splits validation from resolving. That validator
is closer to PKI than to the DNS.

TL: expands, DNSSEC was designed for preventing DNS problems like
cache pollution. We are now discussing how applications would like to
authenticate. While the caching forwarders must distinguish valid
(secured and unsecured) data from bogus data, the applications may
only want to know whether a query response is secure or not.

SW: Is it sufficient to require to have end host have full resolvers
so we can get rid off resolver-resolver or to push the full security
aware resolvers into applications so you can rid of the API?

To prevent cache poisoning one needs to do validation at the cache.

DFK: Having to put validators in apps will delay deployment because
the legacy resolvers are not protected.

SW: Putting the validator at the application sets requirements to cache.

DFK: Feels that the complications related to this discussion may not
be beneficial to deployment.


Back to the presentation. With all these ideas floating around we
might end up with competing different solutions. Will this ever be a
DNS protocol?

There was some discussion on where this problem needs to be solved and
if the IETF is the proper forum. Miek has not found a IETF WG to adopt
his draft.

Where do we have to discuss these requirements to make sure that we
converge?

LD: Suggest to move Miek's draft to the application area in the IETF.

MG: Asked a clarifying question: will the application do the validation.

BM: The application will drive the validation.

MG: Feels that applications should not implement a validator

BM: If that happens it should show the same external behavior as the
'other' validators.

MG: Process does resolving and validation.
Administrator can set local policy for the whole machine
Application can do apply the second phase of local policy.

OK: Fears that working on the requirements will take years unless we
find the most simple common ground. Is there a complete set of
requirements like Miek suggests or are there *many* more requirements
like Bill suggests. If we go down for solving all problems it will
never converge.

DFK: Find essential elements.

MG: We will need to enumerate what are the error cases are that we can
end up with.


TL: Concludes by reminding the audience that we can secure the
infrastructure today. And that getting validator info to the
application is a "second" phase.

----------------------------------------------------------------------
F. AOB

Nothing.