Subject: [keyassure] who to trust

From: Tony Finch <[email-masked]>
Date: Fri, 20 Aug 2010 02:01:05 +0100

It seems to me from this week's discussion that (exaggerating slightly) no
one wants to trust the x.509 certificate authorities and no one wants to
trust ICANN's DNSSEC root anchor. So how can users decouple their trust
anchors for their important applications (banking! email!) from third
parties that they don't want to trust very much?

At the moment most crypto implementations have one of two models (ignoring
weird geeky outliers):

(a) Stateless trusted third party. Like SSL / X.509. Forget any past
interactions with the service, all you care about is whether its
certificate is signed with any of innumerable minimally trustworthy third
parties.

(b) Static trust anchor configuration, established manually or with a
semi-manual ssh-style leap of faith. Any disagreement is an attack.

Neither of these support key rollover properly. In case (a) a client
cannot tell the difference between a key rollover and an exploit against
an untrustworthy CA. In case (b) a key rollover is a festival of exciting
warnings, just like a man-in-the-middle attack.

There is a better solution between these extremes, where a chain of
signatures maintains trust across key rollovers. This model is used with
more or less automation by RFC 5011 and PGP. It means you only need to
trust third parties to establish initial authentication, after which your
ongoing relationship with the second party maintains that authentication.

So perhaps this group should see its job as providing another way
(alongside x.509 / pgp / etc) of authenticating an initial introduction to
a service, or of re-establishing authentication after a hiatus. After that
introduction apps should maintain an independent trust relationship.

The fact that apps do not maintain trust relationships across key
rollovers in this way is a very important problem. I do not think this
group is the right one to solve it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
PORTLAND PLYMOUTH NORTH BISCAY: SOUTHERLY OR SOUTHWESTERLY 5 TO 7. MODERATE OR
ROUGH. RAIN OR DRIZZLE. MODERATE OR POOR.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Aug 2010 18:16:04 -0700

At 2:01 AM +0100 8/20/10, Tony Finch wrote:
>trust ICANN's DNSSEC root anchor.

Exaggerating wildly, I would say. Who other than Phill have said they don't trust ICANN's DNSSEC root anchor?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 23:27:37 -0400

+1

All this trust anchor discussion is really irrelevant to protocol  
design.  We just make the chains, the relying parties choose what  
trust anchors to hang them from.

--Richard

On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote:

> Exaggerating wildly, I would say. Who other than Phill have said  
> they don't trust ICANN's DNSSEC root anchor?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Scott Rea <[email-masked]>
Date: Fri, 20 Aug 2010 06:43:23 -0400

> Exaggerating wildly, I would say. Who other than Phill have said they don't trust ICANN's DNSSEC root anchor?
Hmmm... nothing against ICANN personally, but lots against a single 
point of failure, I prefer to share that responsibility around

-- 
Scott Rea
Sr PKI Architect (Contractor)
Em: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 10:25:18 -0400

That is precisely my position.

If people want to propose a system with a single point of failure then
that point of failure has to be on the table for discussion. The only
reason I brought ICANN up is that others insisted that we only design
a system where the only choice is to trust the ICANN monopoly.

I do not think that we want two separate groups, one to do DNSSEC for
applications using only the ICANN root and a separate group for
applications using a choice of roots. And even if we wanted to, I
doubt that a charter of that nature could be accepted by the IESG.

One other charter point. We cannot have any discussion of pricing of
products or services (including 'free'). IETF rules have been quite
lax on this point to date. However we have to take care not to be the
group that brings down the lawyers.

On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea <[email-masked]> wrote:
> Hmmm... nothing against ICANN personally, but lots against a single point of
> failure, I prefer to share that responsibility around
>
> --
> Scott Rea

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Aug 2010 10:40:08 -0400

> a system where the only choice is to trust the ICANN monopoly.

[Citation needed]

> doubt that a charter of that nature could be accepted by the IESG.

Obviously we don't, because this whole discussion is completely  
unrelated to a choice of trust anchors.  DNSSEC and other protocols we  
develop in the IETF do not require any relying party to use any given  
trust anchor.  If you want a concrete example, just look at the DLV.

> group that brings down the lawyers.

That seems kind of obvious.  Who has expressed a desire to discuss  
pricing?

--Richard

>>>> It seems to me from this week's discussion that (exaggerating  
>>>> slightly)
>>>> no
>> point of

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 10:46:41 -0400

Plenty of people have asserted that the objective is to do PKI for
'free'. Others have expressed the opinion that certain services are
'overpriced'.

Those are pricing discussions.

If you read the other charter proposals you will see that they both
contain statements to the effect that the advantage the group seeks to
realize is to enforce use of a single root of trust. Those are the
parts I find unacceptable.

On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes <[email-masked]> wrote:
> Obviously we don't, because this whole discussion is completely unrelated to
> a choice of trust anchors.  DNSSEC and other protocols we develop in the
> IETF do not require any relying party to use any given trust anchor.  If you
> want a concrete example, just look at the DLV.
>
>
> That seems kind of obvious.  Who has expressed a desire to discuss pricing?
>
> --Richard
>
>
>
>
>>
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Aug 2010 10:55:14 -0400

Ah, I have only just now read the initial charter proposal that Warren  
sent out.  I agree that that one is too root-centric.

But clearly the problem can be phrased more in terms of application  
needs (binding keys to domain names) and validation paths (overlaid on  
DNS) instead of what TAs those paths end in.  That's what I tried to  
do in my earlier proposal.

On Aug 20, 2010, at 10:46 AM, Phillip Hallam-Baker wrote:

>> unrelated to
>>>>>> one wants to trust the x.509 certificate authorities and no one  
>>>>>> wants
>>>>>> to
>>>> Hmmm... nothing against ICANN personally, but lots against a  
>>>> single point
>>>> of

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 20 Aug 2010 17:04:24 +0200

> parts I find unacceptable.

Just to repeat what Paul already said.  You seem to be the only one who 
complains.  Or is there anybody else who has similar objections?  If you 
are out there, please speak up.

I would like to remind you that the IETF process works on rough 
consensus.  Right now my feeling is that you are standing alone with 
your opinions on what is acceptable and what is not.  And that's a 
hardly rough consensus to change the charter.

I don't want to say that I (and other people) won't hear your complaints 
and won't change the charter, but "plenty of people" (to cite you) is 
much closer to rough consensus.  I would be happier to find a total 100% 
consensus on our work, but if you barricade yourself in your position 
that would be very very hard to achieve.

I was told that standard IETF process is a way how to have things not 
done and that I am naive to push this through IETF, but I would like to 
prove them wrong.

Ondrej
-- 
  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: Fri, 20 Aug 2010 11:33:48 -0400

An IETF WG charter requires more than consensus amongst the proposers.
There has to be an IETF consensus and the IESG has to concur and there
has to be an AD willing to accept the WG.

Making assertions and then ruling rebuttals as 'off topic' as you keep
doing is not the way to get an IETF charter accepted.

If you want to persist in making a proposal which tries to enforce a
certain trust model then it has to be in the security area. I think
you will find at least one of the security ADs rather skeptical of the
viability of a single rooted model as even the US federal government
could not come to agreement on that architecture.

Consensus does not mean that you get to choose a group of people who
want to do it your way and then get a WG chartered to coronate that
specific proposal.

On Fri, Aug 20, 2010 at 11:04 AM, Ondřej Surý <[email-masked]> wrote:
> complains.  Or is there anybody else who has similar objections?  If you are
> out there, please speak up.
>
> I would like to remind you that the IETF process works on rough consensus.
>  Right now my feeling is that you are standing alone with your opinions on
> what is acceptable and what is not.  And that's a hardly rough consensus to
> change the charter.
>
> I don't want to say that I (and other people) won't hear your complaints and
> won't change the charter, but "plenty of people" (to cite you) is much
> closer to rough consensus.  I would be happier to find a total 100%
> consensus on our work, but if you barricade yourself in your position that
> would be very very hard to achieve.
>
> I was told that standard IETF process is a way how to have things not done
> and that I am naive to push this through IETF, but I would like to prove
> them wrong.
>
> Ondrej
> --
>  Ondřej Surý

---

From: Steve Schultze <[email-masked]>
Date: Fri, 20 Aug 2010 11:43:58 -0400

I like Richard's alternative charter proposal, which incorporates much of what Phillip wrote.  If it's easier to get consensus for it without paragraphs 2 and 3, that's fine.  I think it does a good job of laying out the problem area and scope, which includes the idea that zone controllers directly place key material in their zone.  I think that this functionality is in effect a new (or at least augmented) trust model, but Phillip doesn't think so given that his draft also included language to this effect and he thinks we can't be talking about trust models.  Frankly I don't care whether we call it a trust model or not as long as we get some work done.

In any case, the question of trust _anchor_ selection is out of scope according to both Richard and Phillip's drafts, so let's stop talking about it.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Aug 2010 10:11:53 -0700

I strongly support a charter that specifically ties the gaining of trust that a key/cert is associated with a domain name to the DNS itself, using the DNSSEC protocol as the cryptographic protection for the binding statements. Doing so uses a trust system that is well understood and a protocol that is well understood.

It is fine to propose that a different trust system be used. In order to make that proposal understandable, you can write an Internet Draft that explains the trust system and compares it to the ones commonly in use today (PKIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS responses signed with DNSSEC).

It is fine to propose that DNS responses be used but to use a different cryptographic method for assuring the origin. In order to make that proposal understandable, you can write an Internet Draft that explains the new cryptographic binding, and compare it to DNSSEC.

>doing is not the way to get an IETF charter accepted.

Yes, it is.

Allowing one person to derail the charter discussion because he or his employer doesn't like where it is going is not considered a best practice in the IETF. Instead, if you think that you have a group of people that would support your view, start your own pre-BoF mailing list, show that you have an interested group, and bring that to the IESG.

>certain trust model then it has to be in the security area.

Your "has to be" and "must be" statements are not backed by any known precedent, are they?

>I think

And, at that point, we can continue the discussion with them. So far, you are only speculating in a way that supports your (to this point) lone opinion.

>want to do it your way and then get a WG chartered to coronate that

Nor does it mean listening to one person who repeats arguments over and over without gaining support from others in the discussion. Some of us prefer the former method to the one you are proposing.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 13:34:30 -0400

Since DNSSEC is not deployed, it is clearly not fully understood.

I am not proposing a new trust scheme. I am proposing that we permit
use of either the new trust scheme that you are proposing or the
existing trust scheme that has a 15 year deployment history.

Since my scheme is already deployed and should be well understood by
all participating in these discussions, I fail to see why there is a
need for a draft on my part. If you understand the browser trust root
model you will understand my proposal as being a logical refinement
thereof to introduce more accountability just as I did with my
proposal for EV certs.

However, should you be insisting that the only way that we can
approach this problem is to do it your way and that we cannot listen
to any other, then I am going to keep asking questions that my
experience makes me know to be relevant and which you are not able to
answer.

As for your imputation of a commercial motive here, I suggest that you
consider whether you want to open up that topic of discussion. ICANN
has a commercial relationship to IETF through ISOC. None of us are
communists (well hardly any).

For the record, I was retired from April 2009 and only began
discussions with Comodo a few months back. I made similar observations
in my talk at RSA2010 when I was fully retired. I have made similar
statements in the same time period on the IETF and DNSEXT list. If you
recall, I objected to the notion that there be a single root for the
BGP Security solution.

I believe that your assertions in this regard are unhelpful, unfair
and should be withdrawn immediately.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Aug 2010 13:47:54 -0400

> Since DNSSEC is not deployed, it is clearly not fully understood.

What are you talking about?  It is so deployed.  I can validate
answers from the root.  I can validate isoc.org from the root on down.

If what you are claiming instead is that DNSSEC is not fully deployed
always and everywhere, I don't think that premise even slightly
supports your other claim that DNSSEC is not fully understood.

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

---

From: David Conrad <[email-masked]>
Date: Fri, 20 Aug 2010 11:08:58 -0700

> Since DNSSEC is not deployed, it is clearly not fully understood.

DNSSEC is deployed at the root, at a couple dozen TLDs, and about 24,000 other zones (according to SecSpider).

> existing trust scheme that has a 15 year deployment history.

I believe one of the reasons people are looking at DNSSEC as a way to build a new PKI (to use a shorthand) is because the existing trust schemes have significant flaws. I'm unclear as to why you'd like to import those flaws into the efforts here, but Paul's hypothesis would appear reasonable.
 
> has a commercial relationship to IETF through ISOC.

No it doesn't. This is no direct relationship, commercial or otherwise, between ICANN and ISOC. I'm curious why you think there would be. There is a relationship between ICANN and the IETF (IASA, IAOC, whatever) in the form of performance SLAs for registry modifications, but I have difficulty seeing this as commercial or in any way related to keyassure.

You really should stop making things up -- it damages your credibility.

Regards,
-drc

---

From: Steve Schultze <[email-masked]>
Date: Fri, 20 Aug 2010 15:04:34 -0400

> thereof to introduce more accountability just as I did with my

What is your proposed scheme?  All I can find is:

On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote:
> The simple solution for this is to allow for certs in the dnssec trust path to validate KSKs. This would supplement the TLD signature if available.

Assuming I understand you correctly, it's not clear to me why this is any more secure than the current practice of CAs issuing certs for the leaf node TLS keys themselves.  Putting it in the DNSSEC trust path just perhaps adds a dependency for the DNSSEC TA (I can't tell from your two sentences if it's required to be signed and validated as such).  If you want (DNSSEC TA)+CA, zone controllers can just place the hash of each leaf's CA-issued cert in DNS (which is compatible with the main thrust of this group's proposed direction so far).  If you'r proposing that this is a mechanism for allowing third-party CAs to vouch for a KSK at some higher level of the DNS hierarchy such that they create an alternate trust hierarchy that subverts the exclusive domain-based delegation of the TLDs (and further sub-domains), then there are a whole host of questions which are most certainly outside the scope of what most of us are trying to do here.  As far as I can tell, none of this would have any bearing on a proposed mechanism for placing DNSSEC-signed leaf node key material in DNS (whether it chains to the ICANN root or elsewhere, via locally specified TAs or your scheme).

In any case, I don't intend this as an invitation to start a discussion on the merits but rather as a demonstration of why an I-D and a separate discussion seems appropriate to me as well.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 16:09:03 -0400

Last I heard isoc has a financial interest in .org

Qualifying that with the weasel word direct and claiming it impacts my  
credibility would seem to saymore about yours

Sent from my iPhone

On 20 Aug 2010, at 14:08, David Conrad <[email-masked]> wrote:

> DNSSEC is deployed at the root, at a couple dozen TLDs, and about  
> 24,000 other zones (according to SecSpider).
>
> I believe one of the reasons people are looking at DNSSEC as a way  
> to build a new PKI (to use a shorthand) is because the existing  
> trust schemes have significant flaws. I'm unclear as to why you'd  
> like to import those flaws into the efforts here, but Paul's  
> hypothesis would appear reasonable.
>
> No it doesn't. This is no direct relationship, commercial or  
> otherwise, between ICANN and ISOC. I'm curious why you think there  
> would be. There is a relationship between ICANN and the IETF (IASA,  
> IAOC, whatever) in the form of performance SLAs for registry  
> modifications, but I have difficulty seeing this as commercial or in  
> any way related to keyassure.
>

---

From: David Conrad <[email-masked]>
Date: Fri, 20 Aug 2010 14:25:44 -0700

Phillip,

> Last I heard isoc has a financial interest in .org

So, your logic is that because PIR has a contract with ICANN for the operation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, that this imputes a commercial relationship between IETF and ICANN?  Really?

> Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours

Riiight.  As Randy Bush might say <plonk>.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Aug 2010 18:08:13 -0400

You know for people who say they want to focus on technology, you do
all keep digging.

Damn right I consider forming PIR as a bidding consortium and
participating in a share of the profits on the award of the contract
to be a commercial relationship.

By the way, agenda denial is not a particularly effective tactic on
me. I keep attempting to engage on technical proposals, I note that
instead you and others prefer to focus on the assumptions on which my
proposals are based and make assertions that you then declare to be
off limits for discussion and then declare the conversation closed.