Subject: [dnsext] Some reminders about IETF 78 sessions

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Jul 2010 15:41:28 -0400

Dear colleagues,

The latest, revised agenda for the IETF meetings is up.  Please
contact us as soon as possible if you see something either missing
that ought to be there, or something that ought not to be but is.  If
you have a _new_ request for time in the meeting, I expect we will not
allow it.  We asked some time ago for requests, and what you see now
is in accordance with what we received.

CHARTER
=======

I note that there has been very little discussion of the draft
charter, except that we've had a couple proposals to shorten
timelines.  Is there really nothing else to say on this?  If so, we
can steal some time from the 25 minutes on the agenda already devoted
to the topic of the charter, and use it for the aliasing discussion
(which already threatens to take over the agenda).  Is there even one
objection from anyone to any of the proposed charter (see
http://www.psg.com/lists/namedroppers/namedroppers.2010/msg01836.html
if you don't remember it), apart from the dates?  If we hear nothing
before Sunday, we may adjust the agenda to take more of that 25
minutes away.

MEETING MATERIALS
=================

If you plan to speak to your draft during the session, and you have
materials you want to be up on the screen, you MUST send me those
materials by Sunday 19:00 local time for Monday's session, and by
Tuesday 19:00 local time for Wednesday's session.  We will not pause
to accept new materials during the meeting, or to upload them.  If we
have not posted the files prior to the meeting session, they won't go
up on the screen.  You may send files to me in PowerPoint or PDF
formats.  Please don't send Keynote files, because I don't believe
we'll be able to project them.

SCRIBES AND JABBER SCRIBES
==========================

Anyone wishing to perform one of these invaluable services to the WG
is encouraged to contact Olafur or me (or ideally, both, at
[email-masked]) in advance of the meeting to get this
sorted.  If you're a new participant in the WG, this is an excellent
way to dive into participation, and I encourage you to volunteer.
(Note that your newness will also give us an even greater reason to
harass people for not speaking their names into the mics.)

TWO SESSIONS
============

A reminder that we have two sessions at this IETF meeting, but only
one of them is really devoted to detailed DNS topics.  The second
session is intended to get input from the wider IETF community, so we
expect participants in the WG meetings who may not have as great a
grasp of DNS fundamentals as we might usually expect.  Be nice ;-)

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jul 2010 22:46:31 +0000

> Date: Wed, 21 Jul 2010 15:41:28 -0400
> From: Andrew Sullivan <[email-masked]>
> ...
> CHARTER
> =======
> 
> timelines.  Is there really nothing else to say on this?  ...

i consider the comments i made, which had the following headers...

+---
| From: Paul Vixie <[email-masked]>
| To: [email-masked]
| Subject: Re: [dnsext] Reminder: draft charter was posted for discussion 
| In-Reply-To: Your message of "Mon, 05 Jul 2010 14:06:41 -0400."
|              <[email-masked]> 
| References: <[email-masked]> 
| Date: Thu, 08 Jul 2010 01:54:36 +0000
| Message-ID: <[email-masked]>
+---

...to have been substantive.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Jul 2010 22:12:34 -0400

Oh, stupid me. My apologies. You're right. No stealing of time. Sorry for forgetting about this & thanks for the reminder. 

-- 
Andrew Sullivan
<[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Jul 2010 22:56:15 -0400

"* Last mile (recursive to stub) mechanisms that complement, or are
  alternatives to, TSIG and SIG(0); specifically including stub DNSSEC
  validation and protocol extensions to support same."

This bullet point almost addresses the first set of concerns I raised.

I like what DNS Curve is trying to do. But I think that the same
objective might be achieved more simply and easily by beefing up TSIG
to add a simple key exchange protocol. It is possible that we would
want to go one step further and introduce a slightly more elaborate
packet format so that we could use a ticket type system to tell the
server what key to use for signature.

This is not the only case where channel security is useful though. I
have been setting up a home DNS for testing recently and it soon
becomes apparent that dynamic DNS is cool, but I would really like to
use asymmetric keying.

So I agree with Paul's objective here, there is a set of problems for
which channel security works, but it certainly does not address every
DNS authentication need.

-- 
Website: http://hallambaker.com/

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Jul 2010 15:39:47 +0100

On Wed, 21 Jul 2010, Phillip Hallam-Baker wrote:

> It is possible that we would want to go one step further and introduce a
> slightly more elaborate packet format so that we could use a ticket type
> system to tell the server what key to use for signature.

Isn't that already the job of the TSIG RR owner name?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOLE: NORTH, BACKING WEST OR SOUTHWEST, 5 OR 6. MODERATE OR ROUGH. SHOWERS,
RAIN LATER IN WEST. MODERATE OR GOOD.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Jul 2010 15:44:57 +0000

> From: Paul Vixie <[email-masked]>
> Date: Wed, 21 Jul 2010 22:46:31 +0000
> 

one note. since i won't be in maastricht and i seem to be in the minority
of those who think the charter's treatment of "security" should be tighter,
i hope that those at the meetings will realize and remember that the WG is
the mailing list not the people in the room.  therefore, after discussion
of the charter in maastricht by those present, i'm expecting another chance
to reconsider/reformulate my views of whatever draft charter comes out of
that meeting, here on the mailing list.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Jul 2010 11:44:51 -0400

> Isn't that already the job of the TSIG RR owner name?

A TSIG RR name could be used, but if you combine that with a key
exchange you then need to have a registry mapping names to keys.

That is simple enough with one server involved, but gets more complex
with two and next to impossible with a hundred resolving servers
serving millions of users via ANYCAST - as I would hope would be the
case eventually with Google and 8.8.8.8

I don't want to get too deep into this in a charter discussion, but a
better approach from the scalability point of view is to make it
possible to translate a name to a key without the need to rely on
per-end-point data.

Simple way to do this is to issue a Kerberos ticket type entity in
which the label part can be decoded using a locally held symmetric key
to obtain the session key for the corresponding entity.

It is a feature I really regret not having put into SSL early on. Once
issued a ticket might last for an hour or a year depending on what the
security concerns are.

I am not saying we should do this, or that we can't hack the existing
system to obtain the same effect. But it is something I want in
charter so it can be considered.

At the moment the DNS protocol has two very different interoperability
constraints but the same protocol serving both. The authoritative
nameserver to resolver/cache link is really hard to change because
there is an immense amount of infrastructure that has to be backwards
compatible. The endpoint to resolver/cache link can and in some cases
is changed quite radically.

At the moment there is the assumption that all DNS is identical and
that a host just uses whatever DNS server is thrown at them by DHCP.
But that leaves them open to evil twin wifi attacks. And with DNSSEC
potentially improving the trustworthiness of some resolvers over
others the choice of DNS resolver is going to matter.

So while it may seem somewhat aggressive for DNSCurve to simply hijack
the whole protocol, the fact is that it can be made to work when both
sides of the conversation know about it. And that may well turn out to
be the correct protocol choice for many circumstances.

I would like to get to a point where when I set up a host I am asked
'what is your trust root for DNS' and I can type in 'google.com' (or
whatever), get back the fingerprint of some crypto material that tells
me that I have done it right and then know after that is complete that
the trusted DNS path for that device will always flow through the
specified root of trust.

If I go to Panera for coffee, my IP service comes from Panera but my
trusted DNS service comes from my chosen provider [and we have to work
out some way to make the WiFi intercept hack work].

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 22 Jul 2010 12:08:34 -0400

On 22/07/2010 11:44 AM, Paul Vixie wrote:
>> From: Paul Vixie<[email-masked]>

If there are changes to the draft charter from the current state
then that will be posted to the mailing list for comment,
before it is sent up to the IESG for ratification.
Similarly if the current version is deemed acceptable by the
"sense-of-the-room" that judgment needs to be confirmed on
the mailing list.

The IESG frequently applies changes to updated charters submitted.

	Olafur

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Jul 2010 17:18:18 +0100

> issued a ticket might last for an hour or a year depending on what the

Hmm, sounds like a request for a new TKEY / TSIG algorithm.

> others the choice of DNS resolver is going to matter.

It matters less if the end point can do its own validation.

> the trusted DNS path for that device will always flow through the

Why not just rely on the root trust anchor?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST FITZROY: NORTHERLY 5 OR 6. MODERATE OR ROUGH. SHOWERS. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Jul 2010 14:48:37 -0400

> Why not just rely on the root trust anchor?

The idea is that once the device knows that it can obtain every other
device configuration automatically. For low performance devices this
includes things like firmware updates. This is not just a root of
trust, it is a root of control.

Part of the exercise here is to avoid the need to do trust management
on the end point devices. If I am floodle.com I want to be able to set
device security policy for every device I own and I want to be able to
ensure that it is maintained consistently across all devices over
future changes.

So the trust anchor I download is going to be a general trust anchor
that describes criteria for evaluating more than just the criteria for
DNSSEC.

If all you want is a lightweight level of trust then you don't need to
check the fingerprint. But the general principle here is that everyone
has the right to decide what their own root of trust is.

* ICANN does not want to meet every set of trust criteria.

* To sell product in China you are likely to be required to embed the
RCANN root of trust instead. I certainly don't want to have to trust
that one.

* I may be using split DNS and use separate keys that are not
published externally for the internal domain.

* I may be using a curated DNS that has intentionally limited
visibility for managing critical infrastructure.

* I may be using a curated rDNS to control firewall traversal.