Subject: [keyassure] Updated Charter (after Beijing)

From: Ondřej Surý <[email-masked]>
Date: Tue, 23 Nov 2010 09:29:59 +0100

Hi there,

We believe we have managed to integrate all the comments, suggestions,
the latest spin at the charter is:
http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

Diffs are:
http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12

We added:
- note about need for DNSSEC
- note about general policy being out of scope
- moved milestones so we have more time to discuss

All was done with cooperation with ADs.  Many thanks to them.

Ondrej & Warren
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Nov 2010 11:46:23 +0000

One hopefully minor nit and one question.

The nit: I assume that "and thus shown to be authentically from the
domain operator" doesn't require e.g. an additional signature other
than that provided by DNSSEC - the "from the domain operator" could
be read to imply that it does require an additional signature. Not
sure how best to re-word that but maybe something like "providing
strong evidence that the public key record has not been tampered
with since being inserted in the DNS" or something. (I'd have no
problem if an additional signature were allowed, e.g. if the record
contained an X.509 cert, but I didn't think we wanted to insist
on that always, at least not in the charter.)

The possibly more substantive question: the charter says that "last
hop" security is needed, but its not clear to me whether this WG will
specify ways to do that for an implementer that doesn't already
know how. (The "or by other means" phrase is pretty vague.) Am I
right in thinking that one of the drafts listed will include that
(by reference is fine if good references exist). If the answer is
yes, then it might be worth saying so, (and maybe get rid of the
"or by other means" phrase). If the answer is no, then I think
that'd be a problem since I'd bet it'd lead to implementers making
the frequently bad assumption that someone else has looked after
the "last hop."

Oh - and I bet a beer the September milestones slip:-)

Ta,
Stephen.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Nov 2010 08:09:32 -0500

I agree with Stephen on the goals.

Unrealistic goals slow things down. They don't make anything happen faster.

What I have seen happen repeatedly in standards processes is groups have
adopted goals they can't possibly meet and then the impossible goals become
the reason not to look at the real issues.

We would have started deployment of DNSSEC in 2002 only some people thought
there was no time to consider real world deployment issues. Then when the EU
privacy thing came up wit literally spent three years arguing over whether
there was time to consider an issue that took 2 months to fix once we were
allowed to consider it.

And don't get me started on SDMI or OpenID.

This particular problem cuts across layers 5, 7 and 8. It is a security
problem.

On Tue, Nov 23, 2010 at 6:46 AM, Stephen Farrell
<[email-masked]>wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 23 Nov 2010 16:42:54 +0100

Phillip,

you said it before and we have consulted the milestones with ADs on our 
last confcall and the result of our agreement is in the updated charter.
So unless you have a specific proposal how we should change the 
milestones and the people here will agree with you, there's no need to 
repeat what you have already said.

Also please keep on topic.  DNSSEC deployment, SDMI or OpenID is out of 
topic here.

Thank you,
Ondrej

On 23.11.2010 14:09, Phillip Hallam-Baker wrote:
> adopted goals they can't possibly meet and then the impossible goals
> become the reason not to look at the real issues.
>
> We would have started deployment of DNSSEC in 2002 only some people
> thought there was no time to consider real world deployment issues. Then
> when the EU privacy thing came up wit literally spent three years
> arguing over whether there was time to consider an issue that took 2
> months to fix once we were allowed to consider it.
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     <http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure?action=diff&version=12>
>      >
>      >
>      > We added:
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Nov 2010 08:04:05 -0800

>on that always, at least not in the charter.)

Fully agree about not wanting to suggest that another signature is needed. Would the following change fix this for you:

Current:
that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC

Proposed:
that these bindings can be integrity-protected using DNSSEC, thus showing them to be authentically from the domain operator,

>know how.

I'm 99% sure that that it is the latter, from what Tim and Sean said at the Beijing meeting.

>(The "or by other means" phrase is pretty vague.) Am I

Agree.

Current:
the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver, securing the connection to remote resolver, or by other means.

Proposed:
the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Nov 2010 11:25:46 -0500 (EST)

> the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be…

I am not sure about "require".  This phrasing excludes usage of passive
attack protection or leap of faith based. Is that intentional?

For instance with an anonsec (ipsec) connection, a non-dnssec secured
key from dns might still be preferred over using a plaintext connection,
or an https connection might still be preferred over an http connection
despite the unverified nature of the (self signed) cert.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Nov 2010 16:31:14 +0000

> that these bindings can be integrity-protected using DNSSEC, thus showing them to be authentically from the domain operator,

Well....doesn't the DNSSEC signature really show (modulo good
key mgmt) that the records are from the domain registrar who
is generally not the domain operator? (Or have I got my
terminology confused?)

We do hope that registrars put in the right stuff, but I
don't believe the DNSSEC signature shows you that.

How about getting rid of the last part:

"that these bindings can be integrity-protected using DNSSEC."

> the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be…

I like that less actually. Maybe its just me (I don't know the
details of what an implementer would have to do), but shouldn't
the WG say how to secure the "last hop"?

To be clear: I don't think this WG should define new ways to
secure the "last hop," I just think saying how that works needs
to be part of the spec - hopefully by reference.

How about:

"the protocols and mechanisms designed by this working group require
securing the "last hop" by operating a local DNS resolver or securing
the connection to remote resolver - this WG will not specify new
mechanisms to secure that hop, but will reference existing
specifications or document existing methods in order to allow
implementations to interoperate securely."

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Nov 2010 12:57:16 -0500

Since the milestones have been changed, the fact that they have not been
changed enough is hardly repeating myself.

The charter is an agreement between the WG and the IETF, not just the AD and
the chairs.

I have stated the reason I think the milestones are poorly chosen, you have
not even stated you think they are achievable, still less given a
justification.

On Tue, Nov 23, 2010 at 10:42 AM, Ondřej Surý <[email-masked]> wrote:

> So unless you have a specific proposal how we should change the milestones
> and the people here will agree with you, there's no need to repeat what you
> have already said.
>
>>    <

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Nov 2010 11:37:49 -0800

At 11:25 AM -0500 11/23/10, Paul Wouters wrote:
>>the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver ...
>>...snip...
>>... by operating a local DNS resolver or securing the connection to remote resolver, neither of which will be specified by this WG.
>

It was, yes. We don't care about passive attacks: seeing what is in the certs that will be used poses no threat to either party. We explicitly do not allow "leap of faith", given that a successful active attacker can make TLS weaker after the proposed changes than before.

>despite the unverified nature of the (self signed) cert.

Even if the client is using anonsec with its chosen recursive resolver, there is an active attack that makes TLS weaker, so that is not good enough.

This WG is *not* discussing the "HTTPS vs HTTP" issue.

At 4:31 PM +0000 11/23/10, Stephen Farrell wrote:
>...snip...

No, and yes. DNSSEC has nothing to do with registrars: it has to do with DNS zone operators. Those might be the same entity, but often is not.

>don't believe the DNSSEC signature shows you that.

Correct: it does not. It shows that the DNS zone operator put in the data that you are looking at.

>"that these bindings can be integrity-protected using DNSSEC."

That's OK too, but given that it might clear up some misconceptions that some people have, maybe it is better to leave it in.

>...snip...

That feels a lot like mission creep to me, but it also points out that the IETF doesn't yet have good advice for doing this. FWIW, "this" is actually two things:
a) Getting the fact that a response was DNSSEC-validated to a host
b) Getting that fact to an application

>to be part of the spec - hopefully by reference.

There is general agreement in the DNS community that we don't have good references on doing (a) above, and we have none at all on doing (b).

>implementations to interoperate securely."

That works for me too.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Nov 2010 19:51:19 +0000

> b) Getting that fact to an application

Continuing the existing digression: I've never understood this
problem: the app does DNSSEC itself. Whatever facts it needs, it gets
for itself. There is no "last hop". Why complicate matters?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Nov 2010 15:17:36 -0500

> for itself. There is no "last hop". Why complicate matters?

Doesn't matter why: its None Of Our Business.  I think the idea here
is to specify how to do something given other deployed pieces of
network goodness.  Specifying all that other goodness is not our job.

No?

A

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

---

From: Steve Schultze <[email-masked]>
Date: Tue, 23 Nov 2010 15:19:06 -0500

> for itself. There is no "last hop". Why complicate matters?

I don't think it's a digression, but rather a question in our critical path.

I'm not sure what you mean when you say that the app does DNSSEC itself.  What is an example?  The reality is that the *most* that most apps do is trust the AD bit, which is entirely insufficient.  I believe that even the Firefox DNSSEC validator built by Ondřej's guys is doing this (and they know what they're doing).  The reality is that client validation is not built into current clients or the underlying crypto libs.  This is why Kaminsky is focusing on several solutions to the problem:

http://www.slideshare.net/RecursionVentures/dki-2

Or have I misunderstood your comment?

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Nov 2010 16:45:07 -0500

On Nov 23, 2010, at 2:51 PM, Ben Laurie wrote:

>> That feels a lot like mission creep to me, but it also points out  
>> that the IETF doesn't yet have good advice for doing this. FWIW,  
>> "this" is actually two things:

Well, some folk would like to be able to provide DNSSEC validating  
resolver as a service, and then something like an SSL VPN / TSIG /  
SIG(0) / similar magic to provide tamper-resistance and protection of  
the AD bit, and then the belief is that the app can just trust this.
This seems like bad juju to me, but the text was included to allow the  
WG to explore the idea and decided...

My personal view is that the app (or OS on the host) should do the  
validation, but...

>> There is general agreement in the DNS community that we don't have  
>> good references on doing (a) above, and we have none at all on  
>> doing (b).

Yup... it seems surprising to me that this isn't an issue that has  
been addressed more (though, not quite surprising enough that I'm  
willing to tackle it myself :-))

>>> implementations to interoperate securely."

+1

W

-- 
There are only 10 types of people in this world -- those who  
understand binary arithmetic and those who don't.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Nov 2010 23:01:44 +0000

On 23/11/10 19:37, Paul Hoffman wrote:
>> (Or have I got my

Ah. So then if the charter talked about zone operators
rather than domain operators that'd sort that out
for this terminology-challenged reader at least.

S.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Nov 2010 20:53:10 -0500

> for this terminology-challenged reader at least.

Hmmm, I have done this, and *think* that it still makes sense / flows well.

I have also added your (Stephen) suggested text on the "last hop" bit... 

I think the we finally have this right, and are getting close to the bikeshed point / tweaking bits 'cos we can...

W

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Nov 2010 21:18:22 -0500 (EST)

> It was, yes. We don't care about passive attacks: seeing what is in the certs that will be used poses no threat to either party. We explicitly do not allow "leap of faith", given that a successful…

Understood. Thanks for the explanation.

Paul