Subject: Re: [keyassure] Moving policy to a different WG

From: Zack Weinberg <[email-masked]>
Date: Fri, 1 Oct 2010 13:46:57 -0700

On Fri, Oct 1, 2010 at 1:03 PM, Paul Hoffman <[email-masked]> wrote:
[...]
> Phill's responses today to the current charter shows that there is still a fairly wide
> rift between different people's views of what policy is wanted and how it should
> be expressed. Much of the interest in forming this WG was for a single issue that
> is arguably not policy: which keys and certificates, when given in-band in a
> security protocol, are to be used by the client.

As an interested observer, an awful lot of the argument on this list
seems to be over
whether or not that is a policy issue.

As a security researcher and Web browser implementor, I'm fine with
splitting out policy assertions of the form "always use TLS for this
site" (which are not conceptually tied to any given key).  But I don't
see that it does anyone any good to define DNS records for key
fingerprints without also defining what it _means_ for a key's
fingerprint to appear in the DNS.  Client software has to be able to
do something with that information, after all.  If this WG cannot come
to any consensus on the meaning of a fingerprint record, _in the
absence_ of any explicit policy records, then we're not doing anything
useful.

I have an opinion about what a fingerprint record should mean, but
I'll save it for a non-meta thread.

zw

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Fri, 1 Oct 2010 15:02:39 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zack Weinberg
> 
> splitting out policy assertions of the form "always use TLS for this site" (which
> are not conceptually tied to any given key).  

Agreed.  I fully support moving this to another WG.  Depending on whether we believe that there should be a all-purpose policy mechanism, or a per-protocol/application one, some of this could take place in WebSec.

>But I don't see that it does
> anyone any good to define DNS records for key fingerprints without also
> defining what it _means_ for a key's fingerprint to appear in the DNS.  Client
> software has to be able to do something with that information, after all.  If
> this WG cannot come to any consensus on the meaning of a fingerprint
> record, _in the absence_ of any explicit policy records, then we're not doing
> anything useful.

Agreed.  This specific question belongs here.

- Andy

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 01 Oct 2010 17:04:28 -0400

> whether or not that is a policy issue.

Right.

> But I don't
> fingerprint to appear in the DNS.

Indeed, the existing CERT subtypes do just that.

> Client software has to be able to

I believe we have consensus that the presence of a DPKIX (or analogous)
record at a name is a positive statement that the key is acceptable for
that name.  The disagreement is about whether DPKIX records are
implicitly exclusive when at least one is present (as in
draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be
optionally made exclusive (one approach being to add the functionality
to draft-hallambaker-esrv).

-- 
Matt

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 1 Oct 2010 14:33:09 -0700

> to draft-hallambaker-esrv).

This is my personal opinion, and only applies to keys used for HTTPS:
I don't think being able to make that positive statement via the DNS
is useful by itself.  All it does (I think, anyway) is provide an
alternative to DV certs.  That may be good for the long-run health of
the net, but it doesn't make any direct improvement to the security of
the web and therefore it's going to be a hard sell to browser vendors.

Exclusivity assertions, though, *do* buy you a real security
increment: safety against corrupt or coerced CAs issuing rogue
certificates, and against blatantly fake certs that users click
through anyway.  Those (particularly the latter) are real-world
problems that browser vendors would love to have immediate-term
solutions to.

(I wouldn't be surprised if this assessment was true for other
application layer protocols as well, but HTTPS is the only one I know
well enough to opine for.)

zw

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Oct 2010 14:43:19 -0700

At 1:46 PM -0700 10/1/10, Zack Weinberg wrote:
>site" (which are not conceptually tied to any given key). 

Good.

>fingerprint to appear in the DNS. 

Fully agree. We have already moved around on this just within our own draft, and having a WG with a consensus process and people contributing text to the WG's draft(s) would be really useful.

>absence_ of any explicit policy records, then we're not doing anything

Yep. Having a security protocol that doesn't explain its semantics is a waste of time.

>I'll save it for a non-meta thread.

Keep thinking about contributing text to the eventual WG document!

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 19:05:12 -0400

My only non-negotiable position are

1) that the exclusive cert enumeration semantics have to be a clearly
distinguished option when using DNSSEC to assure keys

2) That this aspect of security policy does not foreclose a comprehensive
solution to the problem.

As far as the mechanism to use the DNS+DNSSEC goes, we are currently very
close. The only outstanding issues are

1) Identifier to be used to identify the cert format to prevent a
substitution attack and the hash algorithm. I am fine with anything that
does not bias the scheme towards one security protocol. So using the DNS
identifiers would be OK and using ASN.1 would be OK.

I don't want to use TLS identifiers even if the cert type is limited to TLS
as that would mean having to specify different identifiers according to the
protocol to be used which would make coding a general API hellish.

2) Whether to tie the record to one protocol (TLS) or make the key assurance
mechanism protocol neutral with the proviso that an RFC is likely to be
necessary to explain exactly how to use the mechanism with each protocol
covered.

Now it may just be me, but I do not regard those as being irreconcilable.

To deal with the cert enumeration exclusion semantics, I propose two
separate certificate Types:

DIGEST    For assuring certs without exclusive semantics
XDIGEST   For assuring certs and asserting exclusive semantics

We have plenty of certificate type codes and can even use OIDs if necessary.

This makes the use of exclusive semantics a clearly defined option. It is
thus practical to use this mechanism to assure mail server certs and the
like without the risk that publishing a mail server cert will break the Web
server.

What I am insisting on here is a separation between security policy and the
key assurance mechanism. It should not be necessary for me to use a
mechanism that circumvents PKIX path validation for ALL certificates bound
to that domain name in order to use either DNSSEC key validation or security
policy.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Oct 2010 16:33:33 -0700

At 7:05 PM -0400 10/1/10, Phillip Hallam-Baker wrote:
>What I am insisting on here is a separation between security policy and the key assurance mechanism. It should not be necessary for me to use a mechanism that circumvents PKIX path validation for ALL certificates bound to that domain name in order to use either DNSSEC key validation or security policy.

Well, you didn't say that you agreed with the proposition that the two pieces of work be in separate WGs, but it sounds that way from this paragraph. Is that true?

--Paul Hoffman, Director
--VPN Consortium

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 01 Oct 2010 19:30:27 -0400

On Fri, 2010-10-01 at 14:33 -0700, Zack Weinberg wrote:
> alternative to DV certs.

Right, and one that supports secure delegation.  PKIX supports
delegation via name constraints, but they are unsupported in some
popular clients and insecure in others that accept the subject common
name as a DNS name without applying the constraints.  One could fix the
PKIX clients, but I suspect that most people who care about secure
delegation will just switch to DNSSEC where it is already working.

> That may be good for the long-run health of
> certificates,

This is all true.  But note that DNSSEC trust anchors are not immune to
corruption or coercion either, so it may be worth locally configuring
exclusive trust anchors for high-value zones with which one has a
relationship.

> and against blatantly fake certs that users click

You're supposing that browsers would not allow users to override an
exclusive certificate list in DNSSEC, on the grounds that the server is
broken and accepting another certificate would be by definition
incorrect behavior.  Why should we believe that such a tough stance will
be any more viable with DNSSEC than with the current public CA system?
(This isn't a rhetorical question, I want an answer if there is one.)

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 20:24:10 -0400

I am agnostic on the question of number of WGs.

I think that getting a spec like ASSURE/DPKIX/DIGEST ready for submission to
the IESG can be done by January next year.

The XDIGEST/TLSFP approach with the enumeration business is going to take
quite a lot longer. It can possibly be done in a year if it is feasible.

As far as ESRV goes, what I want to do at this stage is to get some real
world deployment experience on an experimental basis. I want a RR assignment
as soon as possible but would not want to be starting on a standards track
effort for a year.

So we really don't need to decide whether this is one WG or two at this
stage.

I suggest the following milestones

Jan 2011  Submit DIGEST mechanism draft to IESG
July 2011 Submit DIGESTX mechanism draft to IESG
July 2011 Submit Using CERT records with TLS draft to IESG
Nov 2011 Submit Using CERT records with IPSEC draft to IESG
Recharter

These are actually pretty aggressive milestones. The WG would have to cover
a lot of work in a short space of time. Getting the group chartered by Jan
might well be ambitious.

Even if the draft of DIGESTX with the enumeration/exclusion semantics is
ready in Jan 2011, the charter has to give the TLS, PKIX and other working
groups a sufficient time to review the impact on their specs.

Note also that getting the draft to the IESG is not the end of the process.
There can be a huge amount of work for the shepherd and the authors after
that point.

The WG is going to have to take a very different approach to work if they
want the spec to exit from the IESG.

On Fri, Oct 1, 2010 at 7:33 PM, Paul Hoffman <[email-masked]> wrote:

> >What I am insisting on here is a separation between security policy and
> the key assurance mechanism. It should not be necessary for me to use a
> Well, you didn't say that you agreed with the proposition that the two
> pieces of work be in separate WGs, but it sounds that way from this
> paragraph. Is that true?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 1 Oct 2010 17:36:48 -0700

> delegation will just switch to DNSSEC where it is already working.

But what good does secure delegation do you in the absence of
exclusivity assertions?  Someone can still come along with a cert they
shouldn't have, courtesy Jim-Bob's Bait Shop and CA, and without an
exclusivity assertion, the browser has no way of knowing it shouldn't
accept it.

(To be honest, though, I'm not sure I know what you mean by secure delegation?)

> exclusive trust anchors for high-value zones with which one has a

As a browser vendor (let me be specific: until this past August I
worked for Mozilla Co., and I am still involved in the project) I am
running on the assumption that local configuration of trust anchors
occurs with probability zero.

> incorrect behavior.

Yes.  STS (http://tools.ietf.org/html/draft-hodges-strict-transport-sec)
is already going there, and this could follow.

> Why should we believe that such a tough stance will

As I understand it, a lot of the problems with the current CA system
are consequences of silent acceptance of conditions that *should*
(from an abstract security point or view) shut down a site.  We're
stuck with that in the existing system lest we break sites that aren't
really being maintained.  But the new scheme is opt-in, so we can
declare that by opting in, you take on certain extra administrative
responsibilities, and in exchange you get these additional security
benefits.  Don't like it? Stick with DV certs, we're not taking that
away.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Oct 2010 17:46:19 -0700

>I am agnostic on the question of number of WGs.

Sounds good. I have removed the policy discussion from the proposed charter at <>.

Please get a mailing list for the policy work set up. If the ADs don't mint you one @ietf.org (but they should), I'm happy to host it at VPNC (because there could be some effect on IPsec) or you can host one at Comodo or something. Be sure to tell this list when it is up and happening.

This split should let both sets of work move forwards more expeditiously.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 1 Oct 2010 21:32:30 -0400

<snip>
> occurs with probability zero

Though it may be close enough to 0%, this is certainly not true a statement.  Plenty of folks clean much of the cruft from their TA store.  At present I can operate my Chrome or IE browsers such that constrained TAs are used for path validation and, for example, EV certificate policies are required.  This partially explains why I don’t want or see value in a flag telling the client what to do validation-wise with the key obtained from DNS.  Unfortunately, the code isn't presently available (but it was demo'ed at a NIST PKI conference and DOD conference last spring).  

For what it's worth, moving policy elsewhere seems like a good thing.  I like the current TLS draft (minus the flag I've groused about previously).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 21:38:50 -0400

I think it good that people are starting to think in terms of the deployment
incentive.

While it is true that yet-another-mechanism for binding keys to domain names
has limited utility by itself, that does not mean that the only use for
binding keys to domain names is the one hidden in in
hoffman-keys-linkage-from-dns or that this is the best way to achieve the
stated goals.

If Google wishes to eliminate weak CAs from their browser then they can do
that tomorrow. They decide who goes on the list, if they are not confident
in the CPS of any of them they should remove the roots.

My preferred approach would be for them to eliminate all user interface
elements for all certs validated at DV or bellow. The browser would accept
self signed, DV and DNSSEC validated keys regardless of source and turn on
TLS without any user notification at all in the primary chrome.

Somehow, I don't think they are going to do that quite yet. But I think they
might if we could get to the position where 90% of Web traffic was encrypted
and insecurity was now the default.

To get to that point, it is necessary to make it possible for any site to
offer an automatic, transparent upgrade to use TLS without additional
out-of-pocket cost.

Just because you can't think of a use for DNSSEC validated keys without the
cert enumeration semantics does not mean that no such uses exist.