Subject: [dane] Opening issues...

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Jul 2011 14:24:46 -0400

Hi all,

So, as many of you know, I've been traveling -- this has led me to slip behind on my email and I apologize for not being more on top of things...

I'm glad to see that there is all of this discussion on the list, but shocked (shocked I tell you) that there are not open issues to track these discussions. I realize that a lot of bright folk are putting lots of time, effort and thought into these discussions, but all this effort is wasted if we don't a: know what it is we are actually discussing and b: track and record what we actually decide[0].

So, *please*, if you have a useful issue or are discussing something of import, please toss it in the issues tracker -- http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize the actual issues under discussion and toss them in, but if y'all do so they'll better capture the crux).

If we don't get some new issues to discuss (yes, and get around to resolving outstanding ones):
1: I'll have to decide that we are all done and move things off to WGLC.
and 
2: We'll all end up sitting around in a big room in Quebec with nothing to talk about or do - if this happens (and to make sure that everyone gets value from their registration fee) I'll have to break out the Karaoke machine.... *Please*, don't make me break out the karaoke machine...

W

[0]: Yes, I realize that all of the email is nicely archived and searchable --  I'm choosing to ignore this point as it a: doesn't support my case and b: interferes with my ranty tone. :-P

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Jul 2011 12:23:09 -0400

> 2: We'll all end up sitting around in a big room in Quebec with nothing to talk about or do - if this happens (and to make sure that everyone gets value from their registration fee) I'll have to br…

I think that the Working Group has made some really good progress with the Use Case doc (thanks Richard, and everyone who contributed) and we stopped work on the Protocol doc to make sure it addressed the use cases correctly.
Since then we have not made much progress (other than some interesting discussions re: serializing DNSSEC chains) and so we might just not have enough to talk about to justify using people's tine in Quebec.

So, if we don't get some issues of substance by Thursday (or requests from folk to present), we'll may just cancel the face-to-face meeting in Quebec... People's time is valuable, and if we don't have anything to discuss we can free some of this up so folk can a: attend other sessions or b: see some of Quebec...

W

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 12 Jul 2011 13:51:53 -0400

> So, if we don't get some issues of substance by Thursday (or requests from folk to present), we'll may just cancel the face-to-face meeting in Quebec... People's time is valuable, and if we don't h…
I think it would be quite valuable to talk about the serialization issue 
that you alluded to above.

Eric

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jul 2011 11:30:13 -0700

On Jul 12, 2011, at 10:51 AM, Eric Osterweil wrote:

> I think it would be quite valuable to talk about the serialization issue that you alluded to above.

While the serializing DNSSEC thread is interesting, is it at all a DANE issue? It feels much more like a TLS issue, since it answers the question "how do I reduce latency in starting up TLS".

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Jul 2011 14:30:29 -0400

I think it would be useful to talk about serialization.

At the moment it seems to be being attacked as not meeting some abstract
model of how the DNS should work.

It seems to me that it is a perfectly reasonable transition strategy. We can
do the problem of distributing keys in the DNS right now and start building
up a user base and operating experience.

Chain serialization is not what I would want as an ultimate solution, but it
solves the initial problem and gets some runs on the board.

If people are going to use DANE at all it has to work 100% of the time when
the user has a DANE aware browser and server. That is already a pretty high
bar to deployment. If we add in a third deployment dependency the likely
outcome is no deployment at all.

Once we get some deployment we can start looking at the problem of how to
get round non-DNSSEC-functional resolvers as a secondary question.

On Tue, Jul 12, 2011 at 1:51 PM, Eric Osterweil <[email-masked]>wrote:

>>> So, as many of you know, I've been traveling -- this has led me to slip
>>> behind on my email and I apologize for not being more on top of things...
>>>
>>> I'm glad to see that there is all of this discussion on the list, but
>>> shocked (shocked I tell you) that there are not open issues to track these
>>> discussions. I realize that a lot of bright folk are putting lots of time,
>>> effort and thought into these discussions, but all this effort is wasted if
>>> we don't a: know what it is we are actually discussing and b: track and
>>> record what we actually decide[0].
>>>
>>> So, *please*, if you have a useful issue or are discussing something of
>>> import, please toss it in the issues tracker --
>>> http://trac.tools.ietf.org/wg/**dane/trac/report<http://trac.tools.ietf.org/wg/dane/trac/report>(I'll also try summarize the actual issues under discussion and toss them
>>> in, but if y'all do so they'll better capture the crux).
>>>
>>> 2: We'll all end up sitting around in a big room in Quebec with nothing
>>> to talk about or do - if this happens (and to make sure that everyone gets
>>> value from their registration fee) I'll have to break out the Karaoke
>>> machine.... *Please*, don't make me break out the karaoke machine...
>>>
>> I think that the Working Group has made some really good progress with the
>> Use Case doc (thanks Richard, and everyone who contributed) and we stopped
>> work on the Protocol doc to make sure it addressed the use cases correctly.
>> Since then we have not made much progress (other than some interesting
>> discussions re: serializing DNSSEC chains) and so we might just not have
>> enough to talk about to justify using people's tine in Quebec.
>>
>> So, if we don't get some issues of substance by Thursday (or requests from
>> folk to present), we'll may just cancel the face-to-face meeting in
>> Quebec... People's time is valuable, and if we don't have anything to
>> discuss we can free some of this up so folk can a: attend other sessions or
>> b: see some of Quebec...
>>
>>
> ______________________________**_________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dane<https://www.ietf.org/mailman/listinfo/dane>
>

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Jul 2011 14:55:55 -0400 (EDT)

On Tue, 12 Jul 2011, Phillip Hallam-Baker wrote:

> Chain serialization is not what I would want as an ultimate solution, but it solves the initial problem and gets some runs on the board.

I don't think it solves "the problem". In fact, I think it is trying to address multiple problems,
and not doing a good job of any.

1) do DNSSEC even if the OS has no secure resolver 
2) secure TLS using DNSSEC
3) reduce DNS(SEC) latency

The problem with 1) is that it seems a lot of work only to protect against passive attacks
(active attacks will leave the vulnerable client on port 80)

The problem with 3) is that if you don't use an DHCP resolver with dnssec or one running on
localhost, every application will need its own "from the root down" dnssec processing and
every app is taking the latency hit and not sharing the cache

IMHO, the enduser is better of running a dnssec validator to reduce DNSSEC latency with
using the DHCP nameserver as forwarder. Shunting dnssec over http, or worse, inline some
certificate container, seems like a lot more code that is very specific to the application,
and does not allow for caching.

People have shown recent statistics saying that EDNS0 / DO bit is not really a problem at large,
so using DNSSEC-chains over alternative transports, while NOT feeding them back into a dnssec
validator on localhost for sharing, does not actually buy us much. It does save us DNS latency,
but I'd address that by keeping a caching resolver on the stub. Doing that also means each
browser does not have to ship a dnssec validator library.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Jul 2011 17:34:10 -0400

Another topic I think we should discuss is the mechanics of how to support
fine grain assertions about keys (e.g. per port or per protocol) which
appear to require use of prefixes to be scalable and support for
wildcards/aliases.

Thus far I see the following options on the table

1) Do not use prefixes
   [Does not provide sufficient granularity, deploying DANE on your mail
server will clobber your Web server]

2) Use only prefixes
   [Not compatible with wildcards due to the ambiguity problem, use of
aliases is problematic]

3) Use a multi-stage resolution in which the first stage is unprefixed and
subsequent stages have additional detail.
   [Saves the appearances but requires two round trips if granularity is
required]

4) Use the DNSSEC trust hierarchy without using DNS (e.g. chain approach].

On Tue, Jul 12, 2011 at 12:23 PM, Warren Kumari <[email-masked]> wrote:

> http://trac.tools.ietf.org/wg/dane/trac/report (I'll also try summarize
> the actual issues under discussion and toss them in, but if y'all do so
> they'll better capture the crux).
> >
> > [0]: Yes, I realize that all of the email is nicely archived and
> searchable --  I'm choosing to ignore this point as it a: doesn't support my
> case and b: interferes with my ranty tone. :-P
> >
> >
> >
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 12 Jul 2011 17:42:01 -0400

Thus it seems appropriate to have some discussion about (1) whether there's interest in stapling/serialization and (2) whether it should be done in DANE vs. PKIX vs. TLS.

--Richard

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Jul 2011 17:49:40 -0400

On Jul 12, 2011, at 5:34 PM, Phillip Hallam-Baker wrote:

> Another topic I think we should discuss is the mechanics of how to support fine grain assertions about keys (e.g. per port or per protocol) which appear to require use of prefixes to be scalable and support for wildcards/aliases.
> 
>    [Does not provide sufficient granularity, deploying DANE on your mail server will clobber your Web server]
> 
> 2) Use only prefixes
>    [Not compatible with wildcards due to the ambiguity problem, use of aliases is problematic]
> 
> 3) Use a multi-stage resolution in which the first stage is unprefixed and subsequent stages have additional detail.
>    [Saves the appearances but requires two round trips if granularity is required]
> 

I believe that we have already discussed (and resolved) this topic:
http://trac.tools.ietf.org/wg/dane/trac/ticket/19

"I believe that this issue has been addressed, both in numerous discussions
and in version -05 of the draft, section 2.1 ("Requested Domain Name")

No-one has objected to the text in the section, so I'm closing this issue.  
If you do object to the text, you must offer alternative (better!)  text...

W
"

This is exactly why having issues in the tracker is useful -- a lot of stuff happens on the list, and it is easy to forget what consensus was reached (this was ~5 months ago!). Having a quick place to refer to is nice...

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Jul 2011 17:51:44 -0400

> If you do object to the text, you must offer alternative (better!)  text...

Ooops, I mean to include Issue #1 as well: 

http://trac.tools.ietf.org/wg/dane/trac/ticket/1

"The rough consensus is that we use a prefix (as opposed to looking up the name and getting back a list of records with ports in them).

Now we just need to settle on the prefix that we will be using - a separate issue (Issue #19 - http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) has been created to decide on this."

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Jul 2011 18:56:03 -0400

We decided against 1.

However we have since done a requirements exercise.

One of the questions raised in that exercise was how DANE would interact
with wildcards and aliases. The current proposal does not support the
correct DNS semantics.

Since the original rationale for not doing the two phase resolution was the
need to have low latency, and since the party that raised that has found
another solution it would seem reasonable to discuss this issue again.

On Tue, Jul 12, 2011 at 5:51 PM, Warren Kumari <[email-masked]> wrote:

> >> Another topic I think we should discuss is the mechanics of how to
> support fine grain assertions about keys (e.g. per port or per protocol)
> which appear to require use of prefixes to be scalable and support for
> wildcards/aliases.
> >>
> >> 3) Use a multi-stage resolution in which the first stage is unprefixed
> and subsequent stages have additional detail.
> "The rough consensus is that we use a prefix (as opposed to looking up the
> name and getting back a list of records with ports in them).
>
> Now we just need to settle on the prefix that we will be using - a separate
> issue (Issue #19 - http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) has
> been created to decide on this."
>
> W
>
>
> > This is exactly why having issues in the tracker is useful -- a lot of
> stuff happens on the list, and it is easy to forget what consensus was
> reached (this was ~5 months ago!). Having a quick place to refer to is
> nice...
> >
> > W
> >
> >
> >>
> >> I think that the Working Group has made some really good progress with
> the Use Case doc (thanks Richard, and everyone who contributed) and we
> stopped work on the Protocol doc to make sure it addressed the use cases
> correctly.
> >> So, if we don't get some issues of substance by Thursday (or requests
> from folk to present), we'll may just cancel the face-to-face meeting in

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jul 2011 16:35:21 -0700

On Jul 12, 2011, at 3:56 PM, Phillip Hallam-Baker wrote:

> One of the questions raised in that exercise was how DANE would interact with wildcards and aliases. The current proposal does not support the correct DNS semantics.

Jakob and I believe that it does. We asked a handful of DNS folks about this, and the result of that discussion is that our usage in the current draft (and the past few drafts) supports CNAMEs just fine. We didn't put this discussion in the current draft, but it is feeling like we should do so in an appendix.

In the meantime (we can't update the draft for about two weeks), if you have specific things from the DNS protocol that you think we are doing wrong, please bring them to the list.

--Paul Hoffman

---

From: Matt DeMoss <[email-masked]>
Date: Wed, 13 Jul 2011 06:10:20 -0400

>
> 1) do DNSSEC even if the OS has no secure resolverThe problem with 1) is
> that it seems a lot of work only to protect against passive attacks

Could that use case better addressed by HSTS?

Where the client does support DNSSEC or some other secure communication from
a trusted authority (or authorities) I could see ways around the initial
request problem, but ultimately you're relying on the user to respond
correctly to some UI cue whether it is the domain name that's displayed or a
lock icon.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 13 Jul 2011 14:39:14 +0200

On 12.7.2011 20:30, Paul Hoffman wrote:
> While the serializing DNSSEC thread is interesting, is it at all a
> DANE issue?  It feels much more like a TLS issue, since it answers the
> question "how do I reduce latency in starting up TLS".

I tend to agree (with chair-hat on) with Paul here.

O.
-- 
 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: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 08:52:53 -0400

Then lets shut DANE down completely and fold it into TLS.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 13 Jul 2011 15:01:57 +0200

> Then lets shut DANE down completely and fold it into TLS.

Please don't do that.  It's not very constructive.

The serializing DNSSEC into TLS is interesting, but I don't think it
fits into our charter.

We could always recharter if the working group wants it.  We always have
that option.

O.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 09:37:39 -0400

> The serializing DNSSEC into TLS is interesting, but I don't think it

I look at a WG as being directed to solve a problem

Your view seems to be that a WG is defined by the means of addressing that
problem.

That second approach is fine if you have a problem that can be addressed
cleanly in the current architecture. Jabber for example is pretty
straightforward as it sits on existing platforms and has minimal
dependencies.

I don't think that approach works at all well here where there is a trivial
problem (putting keys into the DNS) and a very hard problem (making use of
those keys practical under real world constraints). From the start this
group has only wanted to look at the trivial problem. Attempts to address
the practical problems have been rejected as 'out of scope'.

When I have a hard problem and a trivial one I want to be able to use
whatever flexibility I have in solving the trivial one to give me room to
maneuver on the hard one.

I don't think it is at all helpful for a clique to insist that it is only
going to solve the trivial problem and that they are going to ignore the
practical problem completely.

Adam has actual measurements to back up his claim that support for unknown
records is absent in a prohibitively large number of places. The only thing
that surprises me about his numbers is that I expected them to be much
worse. That is possibly an artifact of doing the measurements on Linux.

> that option.

No, you have that option as long as the ADs decide that you have it.

The only reason that you would need to recharter to look at the DNSSEC chain
would be if your AD was telling you that was necessary. And if the AD is
telling you that they are likely telling you 'don't do it' anyway.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 13 Jul 2011 07:24:45 -0700

On Jul 13, 2011, at 6:37 AM, Phillip Hallam-Baker wrote:
> Adam has actual measurements to back up his claim that support for unknown records is absent in a prohibitively large number of places. The only thing that surprises me about his numbers is that I expected them to be much worse. That is possibly an artifact of doing the measurements on Linux.

Its better than you think, but not great, when measured through Netalyzr.  http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf

As importantly, its basically the same as TXT records, and its the same ones which fail.

But more importantly, although we don't have the code to test for it yet, I suspect that the same set of resolvers that can't handle unknown resource records is the same set that strips/chokes on DNSSEC records so you can't get DS records, NSEC/NSEC3, etc...

Client resolvers for DNSSEC MUST validate locally (the recursive resolver can't be trusted, full stop), and MUST be willing to bypass the recursive resolver infrastructure (the recursive resolver may fail to pass DNSSEC-related records properly).

As such, new RRTYPEs work just fine most of the time from the recursive resolver, and when they don't, its highly unlikely that the client can get the DNSSEC records to validate ANYTHING from the configured resolver.  

So new RRTYPEs should not be viewed as a particular problem for DNSSEC-based DNS usages.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 10:48:14 -0400

On Wed, Jul 13, 2011 at 10:24 AM, Nicholas Weaver <[email-masked]
> wrote:

> > Adam has actual measurements to back up his claim that support for
> unknown records is absent in a prohibitively large number of places. The
> only thing that surprises me about his numbers is that I expected them to be
> much worse. That is possibly an artifact of doing the measurements on Linux.
>
> Its better than you think, but not great, when measured through Netalyzr.
> http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf

Systematic bias in the measurement approach is going to be an issue. The
range of browsers touching ICSI etc is going to be a biased set.

I prefer a direct measurement.

> But more importantly, although we don't have the code to test for it yet, I
> suspect that the same set of resolvers that can't handle unknown resource
> records is the same set that strips/chokes on DNSSEC records so you can't
> get DS records, NSEC/NSEC3, etc...
>

I agree. But that is not the issue that concerns me.

If DANE is going to be of use it has to work reliably when it is deployed.
That means having a story for how to make it work close to 100% of the time.

We have the following options:

1) Just use DANE records in DNS  (Expect 98% success rate)

2a) Use DNSSEC chain in long life cert (Expect 100% success rate but chain
data supporting cert will expire before cert does)

2b) Use DNSSEC chain in short life cert (Expect 100% success rate with new
browser but now an old browser will be pestered to re-install the self
signed cert every visit)

3) Use DNSSEC chain in OCSP response

3a) Expect 100% success if OCSP response is stapled

3b) Expect 99% success if OCSP response is from separate server.

4) Use DNS information if available, otherwise attempt to pull OCSP response
as backup.

Expect 99.99% success rate

> Client resolvers for DNSSEC MUST validate locally (the recursive resolver
> can't be trusted, full stop), and MUST be willing to bypass the recursive
> resolver infrastructure (the recursive resolver may fail to pass
> DNSSEC-related records properly).
>

Where does it say that in the DNSSEC specs?

The delegated PKI model is very well established and is in use in
environments with very high security requirements.

In control systems design we have to be able to secure communications with
devices that cannot perform public key at all. Odd as it may seem, it is
quite possible to have a device like a $1 PIC controller using TLS without
any onboard public key capability.

[Ob Disclaimer: author holds IP in this area, no license granted, etc.]

In the larger enterprise the PKI parameters are going to be centrally
controlled in any case. The security policy that matters is the one for the
site and not what the individual user might think should be the policy.

In that case it is much more efficient to make the decision centrally and
tell the client what to do. The client is not going to receive any data
direct from an untrusted source.

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 13 Jul 2011 10:46:28 -0400

> Client resolvers for DNSSEC MUST validate locally (the recursive resolver can't be trusted, full stop), and MUST be willing to bypass the recursive resolver infrastructure (the recursive resolver m…

This "full stop" issue may, or may not, be true but one thing I think deserves a "full stop" is that embedding part of DNSSEC's logic in a place that is _not_ DNS suffers a lot of architectural and operational complexity.  Trusting resolvers is one issue, putting data in a different protocols and trying to cobble DNSSEC-like-validation into remote protocols is the issue I think needs attention.  We've seen a lot of one-off DNS resolver implementations and I would argue a lot of _those_ are responsible for the brokeness that you have measured.  Thus, let's be very weary of adding new points of brokeness that report to support DNSSEC-like semantics and then fail to keep up w/ the protocol's evolution.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 13 Jul 2011 10:51:39 -0400

Eric

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 11:50:16 -0400

On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil <[email-masked]>wrote:

> > But more importantly, although we don't have the code to test for it yet,
> I suspect that the same set of resolvers that can't handle unknown resource
> This "full stop" issue may, or may not, be true but one thing I think
> deserves a "full stop" is that embedding part of DNSSEC's logic in a place
> that is _not_ DNS suffers a lot of architectural and operational complexity.
>  Trusting resolvers is one issue, putting data in a different protocols and
> trying to cobble DNSSEC-like-validation into remote protocols is the issue I
> think needs attention.  We've seen a lot of one-off DNS resolver
> implementations and I would argue a lot of _those_ are responsible for the
> brokeness that you have measured.  Thus, let's be very weary of adding new
> points of brokeness that report to support DNSSEC-like semantics and then
> fail to keep up w/ the protocol's evolution.

We saw the same sort of thing with deployment of SET, or rather the
non-deployment as it turned out.

Certain deployment decisions by certain parties meant that we only got one
chance to deploy SET. By the time we had real world experience and knew the
bits that needed fixing we were unable to make changes there or anywhere
else.

PKI systems are inherently complex because they are the interface to the
trust infrastructure of the real world and the real world is complex.

Rather than having people quote what they imagine the end to end principle
to be, I would encourage them to read what David Clark actually wrote. It is
an argument about complexity and in particular the best places to manage
that complexity.

I don;t want to be speaking for David here, but he is not a rigid ideologue
by any stretch of the imagination. The end to end argument is an argument
about practicality and it applies to a specific situation 20 years ago. It
was never intended to be stated as an absolute truth.

It is not an argument about security either. 'End to end' security predated
the Internet and was and is acknowledged to be a form of security that is
desirable in an abstract sense but frequently impractical. One Time Pads
provide provably unbreakable security, Quantum Cryptography is theoretically
unbreakable, but systems built around those schemes have turned out to fail
in the real world because it is just not practical to build and use them in
a perfect way.

At the time the paper was written a computer system capable of running IP
protocols was $200K and up. Micros existed but they were limited to 64Kb of
memory, not really what you want to be writing an IP stack in.

The telephone system has the complexity in the middle because it is a 100
year old system and the middle is the only place that could be easily
changed. It was also at the time the design was chosen a system operated by
one single entity.

The 'end to end' argument is really an argument that you don't want to put
complexity into the inter-network. At the time the client endpoint was the
only other place it could go. For the past 10-15 years we have seen the
difficulty of making changes at the client increase to the point that it is
very difficult to achieve.

The DNS resolver is my preferred point to put DNSSEC processing because it
means that I can upgrade my DNSSEC processing by upgrading that one single
piece of infrastructure. That means that I have to have a secure means of
communicating with my trusted resolver, but that is a solvable problem (e.g.
DPLS).

It is one thing to say that we will not address issues like DPLS and chains
in certs or OCSP, quite another to state that we will write a spec that
insists that the only valid deployment is one that is totally impractical.

The only valid requirement for DANE is that the DNSSEC records MUST have
been validated in a trustworthy fashion. Going beyond that is ideology.
Security reacts really badly to ideology.

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 13 Jul 2011 12:11:33 -0400

<Top posting to make this more readable, sorry all>

I'm not sure who brought up the e2e principle here (before you Phil), but I don't think it is pertinent (oh, btw, I suspect a non-negligible number of us have read that paper).  In fact, I can't quite tell how your argument below is congruent with your earlier arguments.  If you want a deployed resolver that you can control, great.  I didn't see anyone tell you to (or not to) have that.  It simply wasn't a position on this thread. 

Further, your argument about putting processing in one place so that upgrades can be more operationally realistic sounds quite right to me.  Hence, I think having DNSSEC validation done outside of the the validating resolver cuts against the position you have stated below.  Perhaps this will be easier to address in person in Quebec?

Eric

On Jul 13, 2011, at 11:50 AM, Phillip Hallam-Baker wrote:

> On Wed, Jul 13, 2011 at 10:46 AM, Eric Osterweil <[email-masked]> wrote:
> 
> We saw the same sort of thing with deployment of SET, or rather the non-deployment as it turned out.
> 
> Certain deployment decisions by certain parties meant that we only got one chance to deploy SET. By the time we had real world experience and knew the bits that needed fixing we were unable to make changes there or anywhere else.
> 
> 
> PKI systems are inherently complex because they are the interface to the trust infrastructure of the real world and the real world is complex.
> 
> Rather than having people quote what they imagine the end to end principle to be, I would encourage them to read what David Clark actually wrote. It is an argument about complexity and in particular the best places to manage that complexity. 
> 
> I don;t want to be speaking for David here, but he is not a rigid ideologue by any stretch of the imagination. The end to end argument is an argument about practicality and it applies to a specific situation 20 years ago. It was never intended to be stated as an absolute truth.
> 
> It is not an argument about security either. 'End to end' security predated the Internet and was and is acknowledged to be a form of security that is desirable in an abstract sense but frequently impractical. One Time Pads provide provably unbreakable security, Quantum Cryptography is theoretically unbreakable, but systems built around those schemes have turned out to fail in the real world because it is just not practical to build and use them in a perfect way.
> 
> 
> At the time the paper was written a computer system capable of running IP protocols was $200K and up. Micros existed but they were limited to 64Kb of memory, not really what you want to be writing an IP stack in.
> 
> The telephone system has the complexity in the middle because it is a 100 year old system and the middle is the only place that could be easily changed. It was also at the time the design was chosen a system operated by one single entity.
> 
> 
> The 'end to end' argument is really an argument that you don't want to put complexity into the inter-network. At the time the client endpoint was the only other place it could go. For the past 10-15 years we have seen the difficulty of making changes at the client increase to the point that it is very difficult to achieve. 
> 
> The DNS resolver is my preferred point to put DNSSEC processing because it means that I can upgrade my DNSSEC processing by upgrading that one single piece of infrastructure. That means that I have to have a secure means of communicating with my trusted resolver, but that is a solvable problem (e.g. DPLS).
> 
> 
> It is one thing to say that we will not address issues like DPLS and chains in certs or OCSP, quite another to state that we will write a spec that insists that the only valid deployment is one that is totally impractical.
> 
> The only valid requirement for DANE is that the DNSSEC records MUST have been validated in a trustworthy fashion. Going beyond that is ideology. Security reacts really badly to ideology.
>  
> --

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 13 Jul 2011 18:17:41 +0200

Hi all,

you must excuse me, but I fail to see how this text relates to the
subject of the email and the question if we have any open issues we want
to discuss in Quebec.  Could we please a) stick to the subject (or
change the subject of the email) and b) stick to the WG topic.

Also I would recommend re-reading the charter (which we agreed on when
creating this working group by reaching the consensus) again:

> Description of Working Group:
> 
>   Objective:
> 
>   Specify mechanisms and techniques that allow Internet applications to
>   establish cryptographically secured communications by using information
>   distributed through DNSSEC for discovering and authenticating public
>   keys which are associated with a service located at a domain name.
> 
>   Problem Statement:
> 
>   Entities on the Internet are usually identified using domain names and
>   forming a cryptographically secured connection to the entity requires
>   the entity to authenticate its name. For instance, in HTTPS, a server
>   responding to a query for <https://www.example.com> is expected to
>   authenticate as "www.example.com". Security protocols such as TLS and
>   IPsec accomplish this authentication by allowing an endpoint to prove
>   ownership of a private key whose corresponding public key is somehow
>   bound to the name being authenticated. As a pre-requisite for
>   authentication, then, these protocols require a mechanism for bindings
>   to be asserted between public keys and domain names.
> 
>   DNSSEC provides a mechanism for a zone operator to sign DNS
>   information directly, using keys that are bound to the domain by the
>   parent domain; relying parties can continue this chain up to any trust
>   anchor that they accept. In this way, bindings of keys to domains are
>   asserted not by external entities, but by the entities that operate the
>   DNS. In addition, this technique inherently limits the scope of any
>   given entity to the names in zones he controls.
> 
>   This working group will develop mechanisms for zone operators to
>   present bindings between names within their control and public keys, in
>   such a way that these bindings can be integrity-protected (and thus
>   shown to be authentically from the zone operator) using DNSSEC and
>   used as a basis for authentication in protocols that use domain names as
>   identifiers. Possible starting points for these deliverables include
>   draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
>   draft-josefsson-keyassure-tls.
> 
>   The mechanisms developed by this group will address bindings between
>   domain names and keys, allowing flexibility for all key-transport
>   mechanisms supported by the application protocols addressed (e.g., both
>   self-signed and CA-issued certificates for use in TLS).
> 
>   The solutions specified by this working group rely upon the security of
>   the DNS to provide source authentication for public keys. The decision
>   whether the chain of trust provided by DNSSEC is sufficient to trust the
>   key, or whether additional mechanisms are required to determine the
>   acceptability of a key, is left to the entity that uses the key
>   material.  In addition to the protections afforded by 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 - 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.
> 
>   Initial deliverables for this working group are limited to distribution
>   of bindings between names within the zone operator's control and public
>   keys.  More general statements of policy for a domain are out of scope,
>   and new tasks in this area may only be adopted through a re-chartering.
> 
>   The group may also create documents that describe how protocol entities
>   can discover and validate these bindings in the execution of specific
>   applications. This work would be done in coordination with the IETF
>   Working Groups responsible for the protocols.

While I found Adam's draft interesting and worthy I really think it
twists the problem around by putting DNSSEC into CERT, while we agreed
to work on putting CERTs into DNSSEC.

Also if we are to take "serialization issue" to Quebec then I would love
to hear more opinions from people who *haven't spoken* yet.  And this
really applies to everybody - please cool your heads before replying.

Thanks,
O.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jul 2011 09:28:38 -0700

> to work on putting CERTs into DNSSEC.

Again: Adam's draft does not mentions putting the DNSSEC information anywhere. It is the serialization only. Others will propose where to put that serialization. There are many proposals (with no drafts) so far.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 12:38:07 -0400

It sounds to me like we are done.

If there are no outstanding issues to discuss in Quebec we should ask the
ADs to issue it as an RFC and declare victory.

None of the other issues seem to fit into the charter as defined. There
seems to be no interest whatsoever in even listening to any practical
constraints on deployment, let alone addressing them.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jul 2011 12:43:02 -0400

On Wed, Jul 13, 2011 at 12:28 PM, Paul Hoffman <[email-masked]>wrote:

> Again: Adam's draft does not mentions putting the DNSSEC information
> anywhere. It is the serialization only. Others will propose where to put
> that serialization. There are many proposals (with no drafts) so far.

Quite true.

I suggest the following:

* The Serialization Draft go to DNSEXT because the question at issue there
is how to process a DNSSEC chain in isolation of DNS protocol.

This is going to be an important and useful capability in its own right.
Knowing what parts of the chain are necessary for archival purposes is
essential if we are to achieve accountability or auditability.

* The 'how to stick chain in PKIX' part goes to PKIX.

This can be a relatively short draft consisting of extension declarations
and security considerations, maybe some protocol.

I don't see any part of this work really being a TLS issue so I would not
propose it go there as others suggest.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jul 2011 09:53:57 -0700

On Jul 13, 2011, at 9:43 AM, Phillip Hallam-Baker wrote:

> I suggest the following:
> 
> * The Serialization Draft go to DNSEXT because the question at issue there is how to process a DNSSEC chain in isolation of DNS protocol.

That is up to Adam, not us.

> This is going to be an important and useful capability in its own right. Knowing what parts of the chain are necessary for archival purposes is essential if we are to achieve accountability or auditability.

Fully agree.

> This can be a relatively short draft consisting of extension declarations and security considerations, maybe some protocol.

You can propose that there.

> I don't see any part of this work really being a TLS issue so I would not propose it go there as others suggest.

Others have suggested ways of using the serialization in TLS that does not involve using PKIX. Those folks can take it to TLS.

FWIW, I have requested a slot in the TLS WG meeting to do a lightning review of the DNSSEC serialization draft and the proposed places where it might appear (both PKIX and TLS).

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Jul 2011 13:41:44 -0400 (EDT)

> <Top posting to make this more readable, sorry all>

thank you!

I've kinda stopped trying to read people's postings made with the gmail web client.
It takes me 30 seconds or more to find out if a block of text is new or quoted.

If you want your postings to get proper attention, teach your MUA how to make
readable posts without assuming coloured html blobs.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Jul 2011 14:41:34 -0400

On Jul 13, 2011, at 12:38 PM, Phillip Hallam-Baker wrote:

> If there are no outstanding issues to discuss in Quebec we should ask the ADs to issue it as an RFC and declare victory.

I realize that you were (probably) being sarcastic here, but I'm beginning to think that this may actually be the correct approach...
Not to declare victory in the sense that the WG is all done[0], but the protocol doc (draft-ietf-dane-protocol-08) looks to be close to fully baked (Paul and Jakob have been integrating the WGs consensus as we arrive at it, have bumped it after the Use Case document, and there have been no real substantive comment received that affect *that* document). The fact that we are revisiting closes issues, etc may mean that we are starting to dink with things that should not be dunked...

The last hop, etc issues may be better dealt with in another document....

> None of the other issues seem to fit into the charter as defined. There seems to be no interest whatsoever in even listening to any practical constraints on deployment, let alone addressing them.

You have repeatedly waved the deployability flag -- the working group seems to feel that the current system *is* deployable, and there have been numerous discussions on this topic. 
There is nothing stopping launching, and then if a more deployable solution presents itself / real world deployment issues *are* encountered, releasing a "You do DANE, but with these additions / tweaks / options for discovery / scaling / etc" document.

W

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 13 Jul 2011 13:24:26 -0700

On Wed, Jul 13, 2011 at 10:41 AM, Paul Wouters <[email-masked]> wrote:
> I've kinda stopped trying to read people's postings made with the gmail web
> client. It takes me 30 seconds or more to find out if a block of text is new or
> quoted.

Folks who would like Gmail to behave more interoperably can persuade
it to do so by clicking the "<< Plain Text" option at the top of any
composition window.  As far as I can tell, this setting is persistent;
you should only have to do it once.  It'll still put your cursor in
the wrong place for replies, and there seems to be no way to get mail
and composition windows in a monospace font, but those are not that
big a deal.

zw

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 14 Jul 2011 11:52:14 +0200

On 13 jul 2011, at 18.43, Phillip Hallam-Baker wrote:

> This is going to be an important and useful capability in its own right. Knowing what parts of the chain are necessary for archival purposes is essential if we are to achieve accountability or audi…

I agree (and this is indeed more of a DNS protocol issue than a DANE issue).

> This can be a relatively short draft consisting of extension declarations and security considerations, maybe some protocol.

I agree (although it is up to PKIX to pick this up).

	jakob