Subject: Re: [pkix] Proposing CAA as PKIX Working Group Item

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Jun 2011 14:28:36 -0400

Folks,

The CAA proposal proposes ways in which a CA can behave to reduce the
likelihood of mis-issuing certs. It calls for a the domain name holder
to publish a DNS record with info about the set of CAs that the DNS
name holder views as authorized to issue certs for that domain. Since PKIX
regularly develops standards that provide guidance re CA operation (to some
extent) CAA seems to be appropriate for consideration as a PKIX
work item. (I am less confident about the discussion of RP behavior, for
some of the reasons cited in discussion on the PKIX list over the 
last few days).

This proposal is currently targeted as Experimental, which seems
appropriate.

My one caveat to PHB is that IF CAA becomes a work item, the final
form of the doc will be subject to the usual WG consensus procedures.
I have discussed this with Stefan and he concurs.

With that said, if PHB wants PKIX to adopt this work, the co-chairs 
are amenable.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Jun 2011 14:18:21 -0700

> This proposal is currently targeted as Experimental, which seems

We have not yet heard of Phill would want that to be the intended status if the WG adopts it.

> With that said, if PHB wants PKIX to adopt this work, the co-chairs are amenable.

Earlier, Phill said "I don't think it very likely that we are going to want to look at a complete redesign. But I could imagine people have ideas for new property tags that could be usefully added." I see likely changes between those two poles, and thus still am quite concerned about whether this is a good use of WG time.

FWIW, I would like to see a protocol based on the idea of "a DNS admin tells prospective CAs who should and should not issue certificates for the DNS name" done in the IETF under normal IETF protocol development rules. The PKIX WG seems like a fine place to do that as long as the CA community believes that they are likely to use our output. My concern is that Phill has already done a lot of work on a specific manifestation of the idea, including the non-trivial task of lining up developers and CAs behind his protocol. If they aren't interested in what could easily be a different protocol coming from the IETF process, there is no reason for us to spend the time on it.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Jun 2011 17:41:53 -0400

>status if the WG adopts it.

I assumed Experimental, because that's what the current draft says, but ...

>Earlier, Phill said "I don't think it very likely that we are going 
>to want to look at a complete redesign. But I could imagine people 
>have ideas for new property tags that could be usefully added." I 
>see likely changes between those two poles, and thus still am quite 
>concerned about whether this is a good use of WG time.

We need to hear from Phil on this.

>FWIW, I would like to see a protocol based on the idea of "a DNS 
>admin tells prospective CAs who should and should not issue 
>certificates for the DNS name" done in the IETF under normal IETF 
>protocol development rules. The PKIX WG seems like a fine place to 
>do that as long as the CA community believes that they are likely to 
>use our output. My concern is that Phill has already done a lot of 
>work on a specific manifestation of the idea, including the 
>non-trivial task of lining up developers and CAs behind his 
>protocol. If they aren't interested in what could easily be a 
>different protocol coming from the IETF process, there is no reason 
>for us to spend the time on it.

ibid.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Jun 2011 19:40:12 -0400

> I assumed Experimental, because that's what the current draft says, but ...

I would prefer to work to make a standard.

The long term objective was to make this a standard, the unknown being how
many iterations on the public spec might be necessary to get it working.

There is a possible difference here between the CAA record and the CAA
standard that emerges from PKIX. If the WG decides to change the syntax of
the record we have to recycle through the DNS world and request a new RR
code. If at that point there is a legacy base of CAA records deployed it
will probably be necessary to document that as Informational or Experimental
for the sake of having a fixed point to refer to.

>>>  I have discussed this with Stefan and he concurs.
Well of course, the whole point of doing this is really about handing over
change control.

>> Earlier, Phill said "I don't think it very likely that we are going to
>> want to look at a complete redesign. But I could imagine people have ideas
>> for new property tags that could be usefully added." I see likely changes
>> between those two poles, and thus still am quite concerned about whether
>> this is a good use of WG time.
>>
>

Given that the origin of PKIX was to develop a profile of an existing ITU
standard, I hardly see how our proposal is likely to prove 'too well
finished for PKIX to consider worth time'.

I have tried to anticipate the type of comments that might arise in the area
of 'style' and aligned CAA with PKIX style tropes accordingly: ASN.1, OIDs
etc and I have tried to do the necessary prep work on the DNS side.

 FWIW, I would like to see a protocol based on the idea of "a DNS admin
>> tells prospective CAs who should and should not issue certificates for the
>> DNS name" done in the IETF under normal IETF protocol development rules. The
>> PKIX WG seems like a fine place to do that as long as the CA community
>> believes that they are likely to use our output. My concern is that Phill
>> has already done a lot of work on a specific manifestation of the idea,
>> including the non-trivial task of lining up developers and CAs behind his
>> protocol. If they aren't interested in what could easily be a different
>> protocol coming from the IETF process, there is no reason for us to spend
>> the time on it.
>
>
Well I guess it might be a matter of personal preference, but I prefer that
when people make a proposal to be reviewed by 100+ people that they first
iterate the proposal a few times amongst a small group of people who are
likely to anticipate 80-90% of the issues.

The point of the standards process in my view is to document the
specification and to hand over change control so that additional use cases
can be considered. It is of course necessary to fix any bugs in the spec
that are discovered but I have never seen it suggested before that
'insufficient bugs to correct' might be an obstacle to adoption as a
standards proposal.

Any commercial backing for CAA is for the 'CAA approach' rather than a
particular realization thereof.

I have of course raised this proposal in CABForum as a forum likely to end
up considering future standards layered on top of the CAA approach. But what
I said there is that they should consider IETF/PKIX as the venue for the
technical discussion and participate directly there.

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Jun 2011 16:53:24 -0700

On Jun 1, 2011, at 4:40 PM, Phillip Hallam-Baker wrote:

> Well of course, the whole point of doing this is really about handing over change control.

Works for me. I support the PKIX WG adopting as a work item (wording taken from the CAA draft's text) "DNS Resource Records that allow a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain".

--Paul Hoffman

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 01 Jun 2011 17:12:37 -0700

Paul Hoffman wrote:
> 
> I support the PKIX WG adopting as a work item (wording taken from the CAA draft's text) "DNS Resource Records that allow a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain".

I haven't read the draft, but from the quote it appears that
this could improve the weakest part of TLS (as it is used
today in browsers) where any of the hundreds of preinstalled
root CAs is trusted to issue a certificate to any possible
domain name.

[CC'ed to the TLS working group]

Mike

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jun 2011 07:10:52 +0300

> root CAs is trusted to issue a certificate to any possible

I'm not opposed to this draft, but I don't think it solves this problem. The issue is not even the dozens of pre-installed root CAs, but that those root CAs can have many many affiliates, whether they're sub-CAs or registration authorities. 

The two famous attacks of the last two years have not been about Verisign or Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the "Verisign trust network" but not Verisign itself. In the recent case it was a small Italian RA. In both cases the problem was an affiliate with not quite best practices that caused the mis-issue.

CAA works if all root CAs and affiliates follow it. That's hundreds or thousands of entities. Any one of them that fails to comply might ignore the CAA record.

PHB says that having the CAA record may aid in assigning blame, and thus perhaps at some point, liability. Remains to be seen, but at least in the short term, CAA is not a panacea.

That's why I believe that the DANE record that is aimed at relying parties is a necessary complement to this work. I know I've said the opposite on the DANE list, but I've changed my mind since then.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 09:45:58 -0400

That is not quite right.

First off, measurement of the failure rate of CAs is rather difficult
because we only actually know the failure rate for CAs that self-report. It
is not zero but it is close enough to being zero that people can work
themselves up into a lather about it.

At the end of the day buffer over-run exploits will still trump any
deficiencies in the CA infrastructure. But those don't have people running
round suggesting urgent remedies because they are too common to bear notice.
CAs and RAs are definitely not the weakest link in the chain here. Anyone
claiming that is either grandstanding or has failed to pay attention.

But more importantly, an RA does not have issuing power by definition. Only
a CA can issue certificates because that is the definition of a CA. The
intention of CAA is that it be enforced by the CA so that an RA cannot issue
a non compliant cert either.

One area where I could see a possible use case for extending CAA would be to
enable better RA management controls. For example the vast majority of the
'RAs' identified in the EFF study are actually intermediate roots assigned
to RAs at educational institutions. Such RAs only have general issuing
powers in a minority of circumstances.

We had some discussion of this after my SAAG presentation.

Here is the issue: some of these controls will be technical and some will be
policy. Some of these controls will be the type of thing IETF likes to work
on and some will not. That is why we have CABForum.

And then another question that naturally comes up is how much of this we
should do in phase 1 and whether we should attempt to do everything at once
or to do the lowest of the low hanging fruit first, gain some experience and
then add in features to support additional use cases.

The final point made is that some CAs may not want to support CAA. I can't
see why this would be so unless either:

1) The technology is deficient (something PKIX might fix).
2) They really want to be able to issue fraudulent certificates.
3) They resist change for the sake of it.
4) It is not yet an IETF standard

Now I have no idea which of the above might apply if any. But the only way
to find out is going to be to deploy.

This is still a worthwhile exercise if the only effect is to identify CAs
that wish to issue fraudulent certificates. The IETF does not have the power
to police such CAs but others do.

On Thu, Jun 2, 2011 at 12:10 AM, Yoav Nir <[email-masked]> wrote:

> >> I support the PKIX WG adopting as a work item (wording taken from the
> CAA draft's text) "DNS Resource Records that allow a DNS domain name holder
> to specify the certificate signing certificate(s) authorized to issue
> certificates for that domain".
> >
> I'm not opposed to this draft, but I don't think it solves this problem.
> The issue is not even the dozens of pre-installed root CAs, but that those
> root CAs can have many many affiliates, whether they're sub-CAs or
> registration authorities.
>
> The two famous attacks of the last two years have not been about Verisign
> or Comodo. The "MD5 sub-CA" was issued by RapidSSL, which is part of the
> "Verisign trust network" but not Verisign itself. In the recent case it was
> a small Italian RA. In both cases the problem was an affiliate with not
> quite best practices that caused the mis-issue.
>
> CAA works if all root CAs and affiliates follow it. That's hundreds or
> thousands of entities. Any one of them that fails to comply might ignore the
> CAA record.
>
> PHB says that having the CAA record may aid in assigning blame, and thus
> perhaps at some point, liability. Remains to be seen, but at least in the
> short term, CAA is not a panacea.
>
> That's why I believe that the DANE record that is aimed at relying parties
> is a necessary complement to this work. I know I've said the opposite on the
> DANE list, but I've changed my mind since then.
>
> Yoav
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Jun 2011 10:03:06 -0400

Phil,

Thanks for your thorough reply. Given the other positive responses, I'm
happy to adopt the CAA concept as a PKIX work item, with the intent that
the target status is standards track, even if an experimental version is
issued first.

Fell free to submit as a PKIX 00, and Stefan or I will approve (he said
as he headed off on vacation for a week ...).

Steve

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Jun 2011 18:37:36 +0300

On Jun 2, 2011, at 4:45 PM, Phillip Hallam-Baker wrote:

> 
> The final point made is that some CAs may not want to support CAA. I can't see why this would be so unless either:
> 
> Now I have no idea which of the above might apply if any. But the only way to find out is going to be to deploy. 

I can offer a couple of others
 5) They're too lazy to care
 6) It's cheaper to not do anything than to do something

In late 2008, when some researchers got RapidSSL to sign a certificate request that collided with their rogue sub-CA certificate, several things came to light:
 - They were using MD5 10 years after RFC 2459 recommended not to
 - They were a ridiculously small company, with the only full-time employee. An accountant
 - They were doing a bunch of other "industry worst practices" - every field in the certificate was predictable

The root problem is that the RapidSSLs of the world issue certificates that are considered by browsers to be just as valid as any DV certificate issued by responsible CAs. So getting a certificate that validates is as easy as getting a rogue certificate from the worst CA or sub-CA. And with so many to choose from, I'm sure it will be possible to find one that didn't implement CAA correctly.

It's still worthwhile, IMO. Because maybe that particular CA that implemented CAA wrong is not using MD5, or maybe they have some other security mechanism done right. It may very well help thwart the next researcher or hacker. I just don't think it's the ultimate solution to the "weakest link" problem.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Thu, 02 Jun 2011 11:07:05 -0500

On 06/02/2011 08:45 AM, Phillip Hallam-Baker wrote:
> deficiencies in the CA infrastructure. But those don't have people
> running round suggesting urgent remedies because they are too common to
> bear notice. CAs and RAs are definitely not the weakest link in the
> chain here. Anyone claiming that is either grandstanding or has failed
> to pay attention.

Well that depends entirely on the chain in question doesn't it?

Not everything that uses TLS or certificates is an unpatched web browser 
with Adobe plugins operated by an ignorant user for the purpose of 
securing nothing particularly important.

Over time it becomes increasingly difficult for _any_ distributed 
application to run over ports other than TCP 443 due to the growth of 
egress filtering. So stuff is bundled in with web traffic that may, in 
fact, be implemented for high security requirements.

Perhaps a solution is to implement your own application-specific trust 
root that doesn't rely on the current profusion of CAs. But as an 
application developer I can attest to the fact that it's difficult to 
use standard platform TLS libraries without also trusting everything in 
the system root store, too. Some sites will insist on using their own 
in-house CAs too, which is fine, but it's further pressure on everything 
else to integrate/be vulnerable with the browser trust model.

The net security world has changed dramatically over the last couple of 
years. We have to move past this 
broken-browser-as-least-common-denominator mentality.

- Marsh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 12:31:13 -0400

On Thu, Jun 2, 2011 at 12:07 PM, Marsh Ray <[email-masked]> wrote:

> with Adobe plugins operated by an ignorant user for the purpose of securing
> nothing particularly important.
>

I hear you.

But lets be realistic here, we are currently actually doing worse for non
browser security.

The weakest link in the TLS protocol is actually the end user who is for
some bizarre reason expected to be looking for padlock icons and green bars
and know when to look for which one.

This is even more problematic when applying TLS to Web services as there
isn't even a user to make the decision and no real idea of what should do
that instead.

CAA is not going to solve every problem associated with trust on the
Internet and CA infrastructure. Nor is TLS and nor is strict security. But I
do think that a combination of those three ideas can make a major step
forward.

That is why CAA is designed to be arbitrarily extensible with a tag-value
format even though there are only two property tags currently defined. I
really like the work that Paypal and Jeff Hodges have been doing and would
like to have a way to eventually bring CAA into alignment there.

But for the moment we have to avoid 'crossing the streams' as Stephen F. put
it to me.

Lets work on the part of the problem that we can while the Web Security folk
work on understanding the complexities of what strict security involves.

> Perhaps a solution is to implement your own application-specific trust root
> that doesn't rely on the current profusion of CAs. But as an application
> developer I can attest to the fact that it's difficult to use standard
> platform TLS libraries without also trusting everything in the system root
> store, too. Some sites will insist on using their own in-house CAs too,
> which is fine, but it's further pressure on everything else to integrate/be
> vulnerable with the browser trust model.
>

Yes and that may well end up motivating a mechanism to allow for protocol
specific path properties so that enterprises can have separate CAs
authorized for separate protocols.

Web Services security is a big part of what I am interested in supporting
here. We went into the Web Services world with certain interests promoting
UDDI as the central directory to make it all work. So now we have a protocol
stack predicated on the existence of a directory with no directory to work
with.

I have some ideas there, but again, that would be crossing the streams at
this point. I think the way to get traction there will be to propose a Web
Service application with some pretty severe security requirements and make
that the test application for a framework designed to 'do it right'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 16:23:05 -0400

OK, it is submitted and waiting first draft approval.

Changes in this version from donotissue-03 are:

* Rights are now Trust (IETF now has change control)
* Target is Standard track
* Name is changed to draft-ietf-pkix-caa-00

If anything else has changed it is a mistake.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jun 2011 14:18:03 -0700

> If anything else has changed it is a mistake.

You didn't remove section 2.3 and the related material that conflicts with the DANE WG?

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 17:21:58 -0400

> You didn't remove section 2.3 and the related material that conflicts with the DANE WG?

So the DANE WG is being territorial now?  How ironic.

The wisdom of the overlap in functionality is still to be discussed, but
there is no "conflict".

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jun 2011 14:30:08 -0700

On Jun 2, 2011, at 2:21 PM, Matt McCutchen wrote:

> So the DANE WG is being territorial now?  

I am a member of the DANE WG and the PKIX WG. I don't speak for either, of course. None of us do.

> How ironic.

Not at all. There is always an agreement that WGs don't do protocols that compete directly with other WGs, if for no other reason than to make the ADs' lives easier.

> The wisdom of the overlap in functionality is still to be discussed, but

If there is significant overlap, there is conflict. There has to be a believable amount of differentiation, where "believable" varies widely based on time and current leadership.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 17:36:43 -0400

On Thu, 2011-06-02 at 14:30 -0700, Paul Hoffman wrote:
> Not at all. There is always an agreement that WGs don't do protocols
> that compete directly with other WGs, if for no other reason than to
> make the ADs' lives easier.

> If there is significant overlap, there is conflict. There has to be a
> believable amount of differentiation, where "believable" varies widely
> based on time and current leadership.

But the determination to remove relying party enforcement from CAA is
far from made at this point.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jun 2011 14:42:39 -0700

> far from made at this point.

Of course, but it also doesn't match anything that Phill talked about in his request to have the CAA concept adopted by this WG. I sort of hoped that Phill would stick to the CAA concept we discussed, namely giving advice to CAs about cert issuance for a domain name.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 18:37:23 -0400

> > How ironic.
>
> Not at all. There is always an agreement that WGs don't do protocols that
> compete directly with other WGs, if for no other reason than to make the
> ADs' lives easier.

Actually this is untrue

I remember when Burt Kaliski proposed S/MIME to the IETF despite the fact
that it was already working on PGP.

SPKI was proposed at the same time as the IETF was working on PKIX.

I would have thought that you knew this.

Note that I am not accepting Paul's premise here, I am merely pointing out
that the claim made by Paul is untrue.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 03 Jun 2011 14:55:34 +1200

Yoav Nir <[email-masked]> writes:

>In late 2008, when some researchers got RapidSSL to sign a certificate
>request that collided with their rogue sub-CA certificate, several things
>came to light:

I wasn't aware of this one, do you have any pointers to info on this?  I guess 
a Webtrust audit doesn't check whether you have more than a single employee :-).

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 02 Jun 2011 22:53:59 -0500

On 06/02/2011 09:55 PM, Peter Gutmann wrote:
> Yoav Nir<[email-masked]>  writes:
>

I think he's referring to Stevens, Sotirov, et al. 2008
http://www.win.tue.nl/hashclash/rogue-ca/
which I'm sure you heard about.

I hadn't heard the part about the single employee though.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 03 Jun 2011 16:03:19 +1200

>I hadn't heard the part about the single employee though.

That's the bit I hadn't heard before.  Sounds a bit minimal for a commercial
CA.  Perhaps the OP confused it with Honest Achmed.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Jun 2011 09:53:41 +0300

> a Webtrust audit doesn't check whether you have more than a single employee :-).

I'm not sure where I've read it. Probably some blog entry about the incident. Not Bruce Schneier's because his entries are still online. 

Anyway, checking the data for now, Business Week has this:
http://investing.businessweek.com/research/stocks/private/people.asp?privcapId=20888814

It lists two "key executives", VP Marketing and VP Sales and no CEO/President. Click their links, and both have other jobs at Globalsign and other companies.

The key issue is the total lack of in-house expertise. Late in 2008, it wasn't RapidSSL that switched to MD5. Verisign did it for them:
http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-RapidSSL-certificates

---

From: koichi sugimoto <[email-masked]>
Date: Tue, 7 Jun 2011 10:31:59 +0900

Dear Sirs,

I've heard the fact was as follows:

-------------------------------------------------------------------------
Paul Tourret and Steve Waite were independent agents assigned the
responsibility of sales and marketing for the RapidSSL brand, acting under
a company called Certification Services Ltd (CSL). Verisign served
termination notice to CSL immediately after the announcement of the
GeoTrust acquisition. CSL then later changed its name to GlobalSign
Limited following successful acquisition of GlobalSign NV. RapidSSL.com
was, and always had been, an SSL brand owned in full by GeoTrust Inc.
GeoTrust elected to represent the brand as a business unit and as
mentioned above, Paul Tourret and Steve Waite were assigned as "agents" to
promote the brand.  All root Certificates and infrastructure was
maintained and operated alongside the GeoTrust branded roots and in
infrastructure operated by GeoTrust Inc.  In 2006 VeriSign acquired
GeoTrust and all its assets, including the RapidSSL brand and root
Certificates.  Paul and Steve ceased their relationship with GeoTrust (now
owned by VeriSign) in late 2006.  At the time of the rogue issuance of
RapidSSL root Certificates, ownership and infrastructure of maintenance
had been under VeriSign's control for over 2 years.  To be clear, VeriSign
did not switch away from MD5 on behalf of RapidSSL, RapidSSL is just a
product brand (not a company) owned in full by VeriSign.
------------------------------------------------------------------------------------------

Regards,
Koichi Sugimoto.

2011/6/5 Yoav Nir <[email-masked]>:
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 08 Jun 2011 18:56:23 +1200

>thousands of entities. Any one of them that fails to comply might ignore the

That was my problem with it, any CA (and/or RA) that's already diligent about 
cert issuance doesn't need CAA, and any one that isn't won't use it anyway, so 
it doesn't address any existing problem.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2011 10:29:35 +0300

> I've heard the fact was as follows:

Thanks for this.

The point remains, that the customers see only the RapidSSL brand, no sign of Verisign on the homepage. And obviously they were running with a very different web application than other Verisign affiliates. Even as just a product brand, some people were assigned to handle the website and the CA, and despite being owned by Verisign, those people apparently weren't doing a very good job.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2011 10:32:48 +0300

> it doesn't address any existing problem.

It would have prevented what has become known as "Comodo-gate". The attacker subverted an RA. If the CA was doing the CAA checking, the attacker would be foiled. If checking the CAA is delegated to the RA, it would not help, but the draft specifically talks about certification authorities.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 08 Jun 2011 19:46:09 +1200

Yoav Nir <[email-masked]> writes:

>It would have prevented what has become known as "Comodo-gate". The attacker
>subverted an RA. If the CA was doing the CAA checking, the attacker would be
>foiled.

> it doesn't address any existing problem.

What makes you class Comodo as a diligent CA?

(Not wanting to re-open the Comodo bashing again, but I'd use "Comodogate" as
a prime example of why CAA won't do much good).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jun 2011 11:37:44 +0300

> What makes you class Comodo as a diligent CA?

What did Comodo fail to do?

The RA is handing contact with the customer, so it's their job to make sure that the customer is in fact the owner of the domain name in the certificate request.

Without CAA, there's nothing left for Comodo to check.

Yoav

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 08 Jun 2011 20:53:26 +1200

>What did Comodo fail to do?

Hmm, this could get back into the Comodo-bashing flamewar, so I'd prefer not
to continue this one... see endless earlier threads on this.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Jun 2011 08:56:10 -0400

First off, I think that people need to stop using the -gate suffix. Just
because a competitor decided that they would attempt to apply it does not
mean it is justified. That is an old game and a rather silly one in our
industry. The relevant cautionary text here being John 8:7.

What differentiates companies in our industry is not whether they are
breached, it is whether they give prompt, voluntary notice of breaches that
occur or not. The market leaders in the CA industry have a track record of
having done so.

As for CAA being a response to the Iranian attack, Ben, Rob and I developed
it a year earlier.

The point of proposals like CAA is not whether they are 'necessary' or not,
it is whether they mitigate risk. I have never seen a security control
involving a human element that is guaranteed to be operated with 100%
accuracy every time. So whenever there are humans involved I like to have
strength in depth.

There would be no problem here if browsers actually implemented revocation
checking either. But we have had that in PKIX specs for 15 years and it
still isn't deployed in hard fail mode. Which is rather sad when you
consider that about 70% of the complexity of PKI comes from the need for
revocation.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Jun 2011 08:56:51 -0400

sorry, that should have been, the previous year. CAA was developed in the
fall of 2010.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 08 Jun 2011 11:58:25 -0500

> What did Comodo fail to do?

If this question is seriously being asked by one as knowledgeable as 
Yoav :-), it suggests to me that the problem is being way over-thinked. 
So forgive me, I'm just going to re-state this bluntly:

The entire value proposition of PKI is based on the trusted root CAs 
refusing to issue fraudulent certs and in this case Comodo, a trusted 
root, failed to refuse to issue certain fraudulent certs.

> The RA is handing contact with the customer, so it's their job to
> make sure that the customer is in fact the owner of the domain name
> in the certificate request.

These legal agreements and auditing procedures only amount to one thing: 
after the victim has been (possibly irreparably) harmed by the issuance 
of a fraudulent certificate, then some legal entity is in a technical 
violation of contract with some other legal entity.

In this case, I've heard of no serious repurcussions other than the loss 
of image to the CA and the RAs. Certainly significant for Comodo, but 
most of the press coverage doesn't even mention the names of the hacked RAs.

Is the CA suing any hacked RA for breach of contract? Are they even 
terminating their agreements?

Are browser vendors removing any root CAs or blacklisting any sub-CAs 
due to this?

What are the costs paid for this debacle as perceived by others with the 
authority to cause the immediate issuance of certs?  Most importantly, 
will these costs always be perceived higher than the immediate gain of a 
corrupt transaction? This is not to suggest any corruption in this case 
of course, but it is surely not going unnoticed for the future that the 
CA, the RAs, and the individuals involved all demonstrated effective 
deniability.

This seems like a good test case to either support or refute the 
arguments of those who claim that policies, auditing, and legal 
agreements between CAs/RAs/subCAs are an effective way to produce strong 
security.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 9 Jun 2011 04:44:07 +0200 (MEST)

Peter Gutmann wrote:
> > thousands of entities. Any one of them that fails to comply might ignore
> > the CAA record.
> 
> That was my problem with it, any CA (and/or RA) that's already diligent
> about cert issuance doesn't need CAA, and any one that isn't won't use
> it anyway, so it doesn't address any existing problem.

You're looking at CAA from the wrong angle.

CAA is _not_ for the RP, i.e. not for _you_ (and me, and most others ...)
It is only another means for a CA to detect attempts to subvert one of
its RAs, so it's primary purpose is CYA for large commercial CAs.

So a Server admin that has a CAA published is not really using it to
_protect_ clients.  It may reduce the likelyhood to get certs
mis-issued, though, and is therefore well in the ballpark of
what businesses are doing to protect against fraud (not protecting
against it, just make it remain under a certain fraud loss threshold).

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jun 2011 09:02:24 +0300

> root, failed to refuse to issue certain fraudulent certs.

Similarly, the value proposition of the DMV is to not issue a driver's license with the name "Marsh Ray" to people who are not Marsh Ray. These days you don't even have to know how to drive.

There is an established "best practice" for how the DMV ascertains who you are: they examine birth certificates, they check street address, etc.

Suppose I go to some RA or CA, and ask for a certificate for www.yoavnir.com, what are they going to do to check?

Obviously, they can check the whois database. This has:

> Registrant:
>    Yoav Nir
> 
>    Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
>    Domain Name: YOAVNIR.COM
> 
>    Domain servers in listed order:
>       NS1.GISIGHT.CO.IL
>       NS2.GISIGHT.CO.IL
> 
> 
>    For complete domain details go to:
>    http://who.godaddy.com/whoischeck.aspx?Domain=YOAVNIR.COM

So far, so good. The registrant name is indeed "Yoav Nir". But we're probably doing this through web or email, so how can they know that I'm actually the same "Yoav Nir"?  Or a "Yoav Nir" at all?  We can check through the link to godaddy (I've removed some of the information):

> Registrant:
> Yoav Nir
> Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329 
> 
> Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
> Domain Name: YOAVNIR.COM
> Created on: 14-Sep-08
> Expires on: 14-Sep-12
> Last Updated on: 25-Jun-10
> 
> Administrative Contact:
> Nir, Yoav [email-masked]
> Amir 1 N/A N/A Kibbutz Amir N/A,12140 Fax. +4.46954329 
> Tel. +972.46954329
> 
> Technical Contact:
> Ltd., Interspace [email-masked]
> 19 Yad Harutzim St. Netanya null,42505 Tel. +972.732224444 

This gives some new information. We have an administrative contact: "[email-masked]" and a technical contact: "[email-masked]"

I have never actually bought an SSL certificate, so I don't know, but I'll have to assume that part of the automated process involves email to one of these addresses. There are also phone numbers, but I can't imagine a DV certificate that costs $10-$40 involving an international phone call by a human.

That's where I would fail. I don't control these email addresses, and the site belongs to another Yoav Nir who's in a totally different line of business.

This is the simple check that a diligent CA can do. But this is as long as the CA is a single entity. 

I don't know of any best practices document that says anything about the division of responsibility between the CA and RA. Is it OK to have only the RA perform the whois check?  Sure, but then what is the added value of the CA?  The reason I like CAA is that it gives an extra layer of security for the CA to perform even assuming that the RA has been subverted.

The way things stand now, I don't see what Comodo could have done differently technically. Sure, we can say that they should not have had a business relationship with an RA that was so easily hackable. Similarly, Verisign should now have allowed rapidssl to use such bad practices. But at the time of the attack, I don't see what check Comodo could have done.

Others (like Peter Gutmann and Bruce Schneier) have written about this before. The model for HTTPS security is what's broken, not a particular CA. There are just too many single points of failure. CAA is an attempt to make the existing model somewhat better, by adding another layer of security - a security check that the CA can do after the RA has already approved the transaction. DANE is a more revolutionary solution that aims to replace or supplement the existing model. I think both have value, with CAA having value much sooner.

Yoav

---

From: Tom Gindin <[email-masked]>
Date: Thu, 9 Jun 2011 08:10:54 -0400

This check seems to be primarily useful when the CA gives high 
(arguably too high) levels of trust to multiple RA's, and the CA is more 
carefully operated than some and perhaps all of its RA's.  Is that 
situation unique to Comodo, or are they the extreme case of a common 
arrangement when there are independent RA's?  This is a reasonable 
suggestion if there are other CA's half as vulnerable as Comodo.

                Tom Gindin
P.S. - The opinions above are mine, and not necessarily those of my 
employer

From:   Phillip Hallam-Baker <[email-masked]>
To:     Peter Gutmann <[email-masked]>
Cc:     [email-masked], [email-masked], [email-masked]
Date:   06/08/2011 08:58 AM
Subject:        Re: [pkix] [TLS] Proposing CAA as PKIX Working Group Item
Sent by:        [email-masked]

On Wed, Jun 8, 2011 at 8:56 AM, Phillip Hallam-Baker <[email-masked]> 
wrote:

What differentiates companies in our industry is not whether they are 
breached, it is whether they give prompt, voluntary notice of breaches 
that occur or not. The market leaders in the CA industry have a track 
record of having done so.

As for CAA being a response to the Iranian attack, Ben, Rob and I 
developed it a year earlier.

The point of proposals like CAA is not whether they are 'necessary' or 
not, it is whether they mitigate risk. I have never seen a security 
control involving a human element that is guaranteed to be operated with 
100% accuracy every time. So whenever there are humans involved I like to 
have strength in depth.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Jun 2011 09:10:48 -0700

> its RAs, so it's primary purpose is CYA for large commercial CAs.

That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly covers relying parties using CAA. I believe that section should be removed, but it is in the current WG document.

--Paul Hoffman

---

From: koichi sugimoto <[email-masked]>
Date: Fri, 10 Jun 2011 13:23:53 +0900

Dear Sirs,

I think so, too.
If CAA prevents only misissuing certificates, then, the section should
be removed.

Regards,
Koichi Sugimoto.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Jun 2011 12:45:56 -0400

CAA was not motivated by the particular circumstances of a single attack
that took place after the proposal was submitted.

I do have a Dalek but I do not yet have a Tardis.

By definition an RA is only responsible for performing validation on behalf
of a CA.

The intention of CAA was that the check always be performed by the CA. Other
parties MAY perform the check in addition.

The issue with respect to RPs comes from the fact that the DNS data is
public (as is required for CAA to work) and thus there is a risk that
someone writes an RP that consumes CAA data even if the spec tells them not
to. Since a certificate MAY be valid for several years it is quite possible
that a certificate was validly issued by an issuer that is no longer
authorized.

Rather than try to tell people not to use a spec for a use case it is
obviously capable of supporting, I think it better to specify direct
support.

The only reason for not doing this is political, not technical. In
particular some members of the DANE working group think that DANE records
should pre-empt PKIX certificate semantics.

If people want to change the semantics of PKIX certificates they have to
come to the PKIX working group. That is the place where PKIX semantics have
been discussed for a decade.

I do not accept the argument that the DANE charter gives it any right to
redefine PKIX certificate semantics let alone an exclusive right.

KEYASSURE was originally proposed as a means to distribute public keys using
the DNS as a base. I still think that is a useful application and that is
what I think DANE should be doing.

On Thu, Jun 9, 2011 at 12:10 PM, Paul Hoffman <[email-masked]> wrote:

> That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly
> covers relying parties using CAA. I believe that section should be removed,
> but it is in the current WG document.
>
> --Paul Hoffman

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 10 Jun 2011 14:12:46 -0400

-----Original Message-----
From: Phillip Hallam-Baker

> The issue with respect to RPs comes from the fact that
> the DNS data is public (as is required for CAA to work)
> and thus there is a risk that someone writes an RP that
> consumes CAA data even if the spec tells them not to.
> Since a certificate MAY be valid for several years it
> is quite possible that a certificate was validly issued
> by an issuer that is no longer authorized.
> 
> Rather than try to tell people not to use a spec for a
> use case it is obviously capable of supporting, I think
> it better to specify direct support.

There is a difference between RPs using public data that is intended for
CAs, and defining additional data explicitly for RP support.  I agree
with the former - you can't and shouldn't prohibit RPs from using a
"trust but verify" approach to flag potential instances of CA
non-conformance.

However, defining Flag Bit 6 (Relying Party Application Use) goes beyond
unintended but tolerated RP use of CA data.  The existence of Bit 6 is
in direct conflict with a statement that "CAA is _not_ for the RP"
(which implied by the penultimate paragraph of section 2:

    "It is the intention of the authors to propose the
     CAA record defined in this document as the basis for
     CA validation requirements ..."

and this from section 2.3:

   "... the Property Entries supported in this version
    of the specification are only designed to support the
    requirements of enforcing issuer restrictions."

There appear to be 3 possibilities going forward:

1) say that RPs MUST NOT retrieve or act on CAA data,
2) say that RPs MAY act on CAA data at their own risk and discretion,
but define no such data specifically for use by RPs, or
3) define RP-specific data (bit 6) and processing rules, with the
expectation that future versions of CAA may define additional property
entries intended to provide complete coverage of RP requirements.

I'm with Paul and Martin, to the extent that they are advocating 2 and
not 1.  The last paragraph of section 2 (time-of-issue vs.
time-of-verification) could be moved to Security Considerations to aid
RPs in understanding CAA.

Dave

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jun 2011 11:20:33 -0700

On Jun 10, 2011, at 9:45 AM, Phillip Hallam-Baker wrote:

> The intention of CAA was that the check always be performed by the CA.

Good.

> Other parties MAY perform the check in addition.

Other parties MAY do whatever they feel like at any time. This is the Internet. The question is whether this WG wants to nudge-nudge-wink-wink encourage them to do so by listing this MAY in the WG document. I propose that the WG does not.

> The issue with respect to RPs comes from the fact that the DNS data is public (as is required for CAA to work) and thus there is a risk that someone writes an RP that consumes CAA data even if the spec tells them not to.

There has not been, as far as I know, a proposal to tell them not to. The proposal is to remove the obvious hint that they might want to.

> Since a certificate MAY be valid for several years it is quite possible that a certificate was validly issued by an issuer that is no longer authorized.

Quite true. That is a use case for the DANE WG.

> Rather than try to tell people not to use a spec for a use case it is obviously capable of supporting, I think it better to specify direct support.

Great: tell them that, if they want to communicate with RPs, use DANE. Or, don't tell them anything and assume that they will use DANE.

> The only reason for not doing this is political, not technical.

Wrong. The reason not to do this is that you are creating two records with similar semantics that, if they don't match, can reduce the security of the host if they have different information in them.

> In particular some members of the DANE working group think that DANE records should pre-empt PKIX certificate semantics.

Hogwash. You have said this many times, and when questioned about what you meant, were not able to describe what "pre-empt PKIX certificate semantics" means in a way that people could understand. Feel free to try again, of course.

For the record: I know of *no one* in the DANE WG who wants to pre-empt PKIX certificate semantics.

> If people want to change the semantics of PKIX certificates they have to come to the PKIX working group. That is the place where PKIX semantics have been discussed for a decade.

True (other than the underestimation of time), but irrelevant.

> I do not accept the argument that the DANE charter gives it any right to redefine PKIX certificate semantics let alone an exclusive right.

Good! We are all in agreement then.

> KEYASSURE was originally proposed as a means to distribute public keys using the DNS as a base. I still think that is a useful application and that is what I think DANE should be doing.

Great! Why do you think that the PKIX WG should undermine that in the CAA protocol? Simply removing section 2.3 would make the CAA proposal much cleaner.

--Paul Hoffman

P.S. It is difficult to have a conversation about a protocol when you try to speak for others whom you clearly disagree with (and when those others, including myself, try to speak for you). In the future, please try harder to state what you believe while refraining from speaking for those with whom you disagree. Thanks!

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 10 Jun 2011 17:37:45 -0400

On Fri, 2011-06-10 at 12:45 -0400, Phillip Hallam-Baker wrote:
> particular some members of the DANE working group think that DANE
> records should pre-empt PKIX certificate semantics.
> 
> If people want to change the semantics of PKIX certificates they have
> to come to the PKIX working group. That is the place where PKIX
> semantics have been discussed for a decade.
> 
> I do not accept the argument that the DANE charter gives it any right
> to redefine PKIX certificate semantics let alone an exclusive right.

Note carefully the difference between "preempt" and "redefine".  DANE
does not redefine PKIX semantics in any way.  "Preempt" is a loaded
word.  Objectively, DANE and PKIX (by which I mean, PKIX validation
against a trust anchor store + a server ID check) are alternative
authentication schemes for TLS services bound to DNS names.  Clients may
feel that DANE has advantages over PKIX and thus choose to use it rather
than PKIX.  I do not accept your tacit assumption that the PKIX WG has
the exclusive right to specify TLS server authentication schemes for use
with the X.509 certificate type.

DANE has significant security advantages over PKIX under a set of
assumptions that are controversial.  OTOH, I have not seen any
substantive claim of an advantage of the CAA RP support over DANE.

-- 
Matt

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Fri, 10 Jun 2011 15:58:11 -0700

On 6/10/2011 2:37 PM, Matt McCutchen wrote:
>    DANE
> does not redefine PKIX semantics in any way.

Hello Matt and all,

Not that this is by itself bad (more why it is not desirable, below) but,  Yes,
DANE redefines the PKIX semantics

Why?

DANE defines a different way (ie, different meaning, different semantics)
to authenticate the association of  the server's certificate with the intended
domain name, and is done without trusting an external  CA. [1]

> assumptions that are controversial.

Intuitively, as more witnesses are considered, it becomes less likely that all 
witnesses
can be compromised at the same time. More Witnesses = Better Evidence. [2]

DANE reduces the number of witnesses over what is needed with PKIX, hence it
can be more easily compromised.  Hence, it is not desirable.

In other words, exactly because the same DNS administrator for a domain name is
authorized under DANE to *both* give identifying information about the zone and
make an authoritative binding between the domain name and a certificate, it should
be less trustworthy. Trust cannot be earned by self-assertions [2].

>   OTOH, I have not seen any

As above.

Cheers,
Ed Gerck

[1] draft-ietf-dane-protocol-07.

[2] The idea that multiple correction channels can be used to offset errors caused
by fraud was already known some 500 years ago in the context of combating
corruption in India, in the Mogul period. The same idea can be proved formally
using Shannon's Information Theory. Google: Gerck Mogul

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 10 Jun 2011 20:19:19 -0400

On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote:
> Yes,

The first statement does not follow from the second.  PKIX is still what
it is; DANE is merely an alternative.  The claim that DANE "redefines"
PKIX seems to be a deduction from the faulty premise that PKIX is the
only possible method of TLS server authentication, and thus the only way
to do differently is to change PKIX.

> be less trustworthy. Trust cannot be earned by self-assertions [2].

This debate has gone around and around on the DANE list, and it is not
productive because the two sides argue from different assumptions that
they are unwilling or unable (for lack of data) to reconcile.  Suffice
it to say that a number of people wish to use DANE, so we are proceeding
with the standardization.

> > substantive claim of an advantage of the CAA RP support over DANE.

I do not understand what you mean.  Please spell it out.

-- 
Matt

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Fri, 10 Jun 2011 18:30:52 -0700

On 6/10/2011 5:19 PM, Matt McCutchen wrote:
>> Yes, DANE redefines the PKIX semantics
>> Why?
>>

The first statement makes no claim on an authoritative source.  The fact that 
folks can
*redefine* the semantics of English so that "cool" means "hot" does not mean that
English is authoritatively changed.

In this case, because DANE changes what it means to "authenticate the server
certificate" (which has so far been defined by PKIX semantics), DANE is indeed
*redefining* the meaning (semantics) that people assign to that sentence.  We now
have two angles to understand the sentence "authenticate the server certificate" .
The DANE and the PKIX angles.

Now, while this may add some degree of confusion (which angle is the browser
using?), I do not say that this is bad or "impossible".  What I say is not that 
this is by
itself bad but that it is not desirable, and I explained why below.

> with the standardization.

My argument did not hinge on popularity.  A number of people may wish to use 
what is
more likely to fail for a number of reasons, including cost.  My argument was that
security-wise DANE is less trustworthy and I explained why using intuitive, 
historical, and
formal arguments. It's not just a theory or an anecdote.

> I do not understand what you mean.  Please spell it out.

Security-wise, DANE is less trustworthy.

Thank you for your comments.

Cheers,
Ed Gerck

---

From: Martin Rex <[email-masked]>
Date: Sat, 11 Jun 2011 04:12:05 +0200 (MEST)

> RPs in understanding CAA.

I'm actually in favour of (1).  There should be as few "mays" as possible
in security specs that can result in interop/communication failures,
because sorting out why product a works and product b fails is extremely
painful for everyone that is affected, or involved in attempts of
finding and fixing the problem.

CAA ought to be for CAs _only_, and RP should look only at DANE.

And personally, I believe that DANE is only useful when DNSSEC
protected.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Jun 2011 22:29:27 -0400

>     CA validation requirements ..."

No it is not.

My intention to build a dalek for my office in no way excludes the
possibility of an Enterprise TOS Command Chair.

The statement above is not exclusive.

>    requirements of enforcing issuer restrictions."

RP restrictions is a much harder problem because the client has much less
information available and the consequences of a false positive are much
worse.

In the issuer case the cost of a false positive is that the request ends up
in exceptions processing. There is going to be a human looking at the issue
and talking to the requester. If they are legit then the DNS record can be
fixed.

I am very skeptical of the likelihood that the browser providers are going
to hard fail on CAA information or DANE information when they still refuse
to hardfail on lack of revocation status.

> RPs in understanding CAA.

Possibility 4 is keep the draft as it is with maybe a more explicit health
warning.

The information in bit 6 is still necessary to enable CAs to be able to
check up on the state of CAA compliance at other CAs.

Whatever people think about the ability of CAs to do their jobs properly I
am sure that our marketing departments will do an exceptional job of
pointing out when competitors fail to do so.

Ergo my expectation is that the observed non-compliance of CAA records will
be low and there should hopefully be little leverage in RP checking in any
case.

---

From: Martin Rex <[email-masked]>
Date: Sat, 11 Jun 2011 04:53:05 +0200 (MEST)

Ed Gerck wrote:
> 
> In this case, because DANE changes what it means to
> "authenticate the server certificate" (which has so far been defined
> by PKIX semantics), DANE is indeed *redefining* the meaning (semantics)
> that people assign to that sentence.  We now have two angles to
> understand the sentence "authenticate the server certificate" .

I'm sorry, but that information is significantly inaccurate.

PKIX defines pretty close to nothing what it means to authenticate
the server certificate, besides indicating that a TLS server cert
MAY contain a specific ExtendedKeyUsage, and certificate path
validation in general (in case there is a path at all) and
entirely independent from the semantic meaning of the certificates
attributes.

What it means to authenticate a TLS Server certificate was loosely
defined by rfc2818 (HTTP over TLS, Informational) describing the
most common behaviour of the installed base, and its inofficial
successor (rfc6125, [tltt], Proposed).

Concerning the trustworthiness, DANE can be anyhing you like.
It can provide a level of trust that are significantly higher
than TLS X.509 PKI alone, by locking down (not completely overriding)
PKIX trust anchors.

You may not like it, but X.509 certs suffer from the birth defect
that they can bear only a single signature, so in PKIX there is
always just one single party asserting an identity.  Effectively
PKIX is hardwired to self-assertion.

While doing a certificate path validation, the PKI software may
be processing a transitional chain of claims of the kind
"oh yes, I assert this party is authorized to make such an assertion",
but there NEVER is any independent confirmation that this assertion
is correct.  In particular, the entity named by an assertion made
by any CA is unable to independently confirm or deny that this
assertion is valid if you're limited to PKIX.  And this is where
DANE comes in for rescue.

Google, Yahoo and whoever else was a victim of Commodo-gate
has been (or would have been) completely unable to deny the
claim made by Commodo.  Only Commodo was able to do something
to make that claim less dangerous (revoke the cert), but ultimately
all of the browser vendors had to issue software patches to ensure
that the incorrect Commodo assertions of identity were really
made invalid.

CAA is Commodos approach to make it less likely that something
like this happens again.

DANE is hopefully going to be the IETF tool to empower the
server and/or domain admin to ensure that any such false claims
independent of how they emerged (fraudulent,accidental
or by governmental coercion), never ever considered trustworthy
in the first place.  Revocation and software patches are slow
and will affect only a fraction of the internet users, and that
problem will _NEVER_ get better.

With DANE, while it has the prerequisite of intial deployment
to reach anyone at all, once that is done, the distribution
will always and constantly get better.

-Martin

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Sat, 11 Jun 2011 01:01:14 -0700

Hello Martin and Matt,

In your reading, is any sentence below NOT to be
understood from draft-ietf-dane-protocol-07?

1. DANE is about a new meaning to the sentence
"authenticate the server certificate".

2. This new meaning differs from the semantics of PKIX.

3. The DANE proposal is to overload issuance (giving identifying
information about the zone) with validation (making an authoritative
binding between the domain name and a certificate), and do so
through the same party (the DNS administrator for a domain name).

Cheers,
Ed Gerck

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jun 2011 15:53:28 +0300

On Jun 10, 2011, at 7:45 PM, Phillip Hallam-Baker wrote:

> CAA was not motivated by the particular circumstances of a single attack that took place after the proposal was submitted.
> 
> By definition an RA is only responsible for performing validation on behalf of a CA.
> 
> The intention of CAA was that the check always be performed by the CA. Other parties MAY perform the check in addition.
> 
> The issue with respect to RPs comes from the fact that the DNS data is public (as is required for CAA to work) and thus there is a risk that someone writes an RP that consumes CAA data even if the spec tells them not to. Since a certificate MAY be valid for several years it is quite possible that a certificate was validly issued by an issuer that is no longer authorized.
> 
> The only reason for not doing this is political, not technical. In particular some members of the DANE working group think that DANE records should pre-empt PKIX certificate semantics.

I can think of a technical reason. Some people have mentioned in previous threads that there should be a "zero record" that says that no CA should issue a certificate. If I get a new certificate once a year, a possible practice would be to have the zero record for my domain all year, and replace it with one for a single CA just before the time to renew a certificate. 

There is no way for an RP to know if my policy is to keep a CAA record for my favorite CA all the time, or to change it frequently. This is different from a DANE record that is intended for the RPs.

More generally, a CAA record is related to my next certificate, whereas a DANE record is about my current certificate.  So unless we actually want the CAA record to be used by RPs, we should not specify it. Even better, the spec should warn RPs against using it.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Jun 2011 09:55:40 -0400

Again you are engaging in invective and insult. Using the -gate suffix is a
tabloid journalism tactic.

Would you like me to write up a blog article on SAPGate the next time your
employer has a security issue?

Pejorative personal attacks and attacks against our employers are not
permitted.

Again, I do not have a time machine. CAA is not a response to an incident
that occurred after the spec was written.

The window of vulnerability for any browser that actually implemented the
existing PKIX specs correctly was less than half an hour.

If you understand the reason why browsers do not implement hardfail on OCSP
you will understand why there is little chance of restriction semantics
being implemented hardfail.

The argument you and Paul seem to be advancing is:

1) PKIX must not intrude on what you define as DANE 'turf'

2) DANE can do any sweet thing it likes on PKIX turf including rewrite the
certificate path validation mechanism.

3) The IETF must not allow anyone to propose an alternative mechanism to
solve the issues you have identified.

4) The market should be allowed to decide whether your proposal is accepted.

I see some inconsistencies there. I also see numerous inconsistencies in
Pauls complains about who is speaking for whom. But I have long since
ignored those

The DANE charter specifies the following:

"The solutions specified by this working group rely upon the security of the
DNS to provide source authentication for public keys."

The charter allows DANE to PROVIDE source authentication of keys. Nowhere
does the charter state that DANE is going to make statements about
certificates.

Now it is possible to read the charter scope more broadly to include
statements about certs and that is quite usual. But if you or Paul had
wanted DANE to have exclusive rights in that respect then you should have
come clean when the group was chartered and actually told the rest of the
IETF that that is what you wanted.

https://datatracker.ietf.org/wg/dane/charter/

Reading the charter gives me no idea that the WG is going to do anything
other than specify a new key distribution mechanism that has no effect on
any other part of the infrastructure. Yes, I know that I knew thats what you
were up to, but you didn't want to tell anyone else.

If the WG wants to have exclusive rights in this respect it is going to have
to recharter in my view. I don't think that is likely to happen. I think it
more likely that an applicability statement would prohibit DANE from
redefining PKIX semantics or defining additional path validation criteria.

If you want to have the prestige and influence of the IETF behind your
proposal you have to play by their rules.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Jun 2011 08:08:03 -0700

On Jun 11, 2011, at 6:55 AM, Phillip Hallam-Baker wrote:

> Again you are engaging in invective and insult. Using the -gate suffix is a tabloid journalism tactic.
> 
> Would you like me to write up a blog article on SAPGate the next time your employer has a security issue?
> 
> Pejorative personal attacks and attacks against our employers are not permitted.

Sure they are: you just did it in the paragraph above.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Jun 2011 08:10:23 -0700

> The argument you and Paul seem to be advancing is: 

False. I am advancing the arguments that I give in my messages, not the ones you attribute to me. Again: please state what you believe, but maybe consider not stating what others believe.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Jun 2011 13:09:13 -0400

No, that really is the case you are making.

It may be rather inconvenient for you to see your points laid out in that
fashion but that is exactly what you have been arguing.

There are three issues here

1) Are the parts of CAA that you are objecting to useful?

I don't think anyone is objecting to the fact that they are.

2) Are they within PKIX charter scope?

They are very clearly within the IETF PKIX charter. They are very clearly
similar to schemes such as OCSP and SCVP that the group has considered
previously.

3) Are they in DANE charter scope?

That is rather less clear because the DANE charter does not actually
explicitly state that it is going to propose the restriction semantics you
describe in your draft.

I find this argument over process to be rather tiresome and irrelevant. I
suggest that if someone has a problem with doing CAA in PKIX that they
propose an applicability statement to the IESG and let them handle it.

I also think that you would be much better advised to remove the restriction
semantics from your own draft until such time as you have demonstrated that
you have an effective and reliable mechanism for key distribution first.

On Sat, Jun 11, 2011 at 11:10 AM, Paul Hoffman <[email-masked]>wrote:

> False. I am advancing the arguments that I give in my messages, not the
> ones you attribute to me. Again: please state what you believe, but maybe
> consider not stating what others believe.
>
> --Paul Hoffman
>
>

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Jun 2011 01:44:58 -0700

>> - They were a ridiculously small company, with the only full-time employee.
...
> http://www.thetechherald.com/article.php/200852/2708/VeriSign-replaces-RapidSSL-certificates

RapidSSL is owned by GeoTrust which at the time was owned by VeriSign
(thus the press release), and now by Symantec.  It wouldn't surprise
me if RapidSSL itself has no employees at all.  I don't think Business
Week's data is reliable in this case.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Jun 2011 14:31:23 -0400

On Sat, Jun 11, 2011 at 8:53 AM, Yoav Nir <[email-masked]> wrote:

> More generally, a CAA record is related to my next certificate, whereas a
> DANE record is about my current certificate.  So unless we actually want the
> CAA record to be used by RPs, we should not specify it. Even better, the
> spec should warn RPs against using it.

The CAA spec is written to permit but not encourage RP checks. The reason
for this is that any protocol change that is deployed in a client becomes
very difficult to undo.

If people decide that they want to use CAA to do that they are going to do
so regardless of any cautionary language in the spec.

Therefore CAA allows the DNS domain owner to tell potential RP checkers that
their particular records MAY or MUST NOT be used for that particular
purpose. That is all that bit 6 does.

We can beef up the cautionary language against that type of checking. I
probably have all the text written already in the use case document.

The people who were originally interested in doing this particular checking
have a client that is almost invariably automatically updated. So they have
a rather interesting situation in that they don't have to consider legacy
issues to the same extent that Microsoft, Apple and others do.

On the other issues, I see two choices

1) We decide that RP checks are a bad idea for technical reasons and neither
DANE nor PKIX specify a mechanism.

2) We decide that RP checks of PKIX certs are an acceptable idea and PKIX
specify them.

I don't see a case for PKIX deciding that RP checks are a good idea but that
they should only be considered by a group of people who frequently express
views that could be seen as hostile to the PKIX architecture and
implementation, do not want to use ASN.1 syntax, do not want to use PKIX
algorithm identifiers and are openly contemptuous of what the PKIX community
has achieved over the past 20 years.

---

From: Scott Schmit <[email-masked]>
Date: Sat, 11 Jun 2011 15:08:13 -0400

On Fri, Jun 10, 2011 at 03:58:11PM -0700, Ed Gerck, Ph.D. wrote:
> DANE defines a different way (ie, different meaning, different
> semantics) to authenticate the association of  the server's
> certificate with the intended domain name, and is done without
> trusting an external  CA. [1]
> 
> Intuitively, as more witnesses are considered, it becomes less likely
> that all witnesses can be compromised at the same time. More Witnesses
> = Better Evidence. [2]
> 
> DANE reduces the number of witnesses over what is needed with PKIX,
> hence it can be more easily compromised.  Hence, it is not desirable.
> 
> In other words, exactly because the same DNS administrator for a
> domain name is authorized under DANE to *both* give identifying
> information about the zone and make an authoritative binding between
> the domain name and a certificate, it should be less trustworthy.
> Trust cannot be earned by self-assertions [2].

You've lost me. In the current Internet HTTPS PKI model, I generate a
key for my HTTPS server. I then go to some CA to get a certificate for
my key. If I opt for a DV certificate, the CA will require that I prove
that I possess the key (via a CSR) and that I have control over the
domain I want it associated with. I'm not sure what all the methods are
for proving this are, but I've heard of using WHOIS-listed email or a
TXT record cookie published by my domain.

Assuming that the email listed in my WHOIS data is hosted by the domain
in question, both of those amount to the CA trusting the person that
controls the DNS records published for the domain.

What's independent about that?

I suppose it's possible that the TXT cookie approach is no longer
considered a good way to prove domain possession, and that WHOIS is the
independent source of information. But that amounts to the domain
registry vouching for the owner of the domain, which they also do when
they publish the DNS NS/DS records.

The only case I've heard where DV certs have an additional benefit over
what DANE provides is in the case of large well-known
domains/businesses, they'll refuse to issue certificates for
typosquatters. But that requires good behavior on the part of every CA.

I don't disagree with you that having multiple sources vouching for the
validity of a certificate is a good thing, but that's not a system we
have now, so it can't be used as an argument against DANE.  At least
with DNSSEC/DANE, I can imagine how DLV-like records can be used to
allow for discoverable certification of key-domain associations from
multiple CAs.

-- 
Scott Schmit

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Sat, 11 Jun 2011 13:44:15 -0700

> What's independent about that?

You are assuming too little.  A PKIX cert can depend on several information
channels independently existing and being independently verified, for example
in identification, issuance, distribution, validation, and revocation.

For example, PKIX includes more than one way to verify cert revocation.
Some of the redundancy and independence is regulated in the CPS, which
can vary in PKIX. For example, a CA may require two forms of identification
with photo and physical presence to a notary before your cert is issued. You
can also have mutually-trusted validation authorities verify if certs are revoked,
not just each issuing CA.

PKIX, unfortunately, also allows ways where there is less separation of powers,
where for example one entity just rubber-stamps what another entity  does
(/sans recourse endorsement/).  But DANE seems to make that the one
and only way (see my quote above).

Cheers,
Ed Gerck

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Jun 2011 21:00:31 +0100

> That's not what draft-ietf-pkix-caa-00.txt says. Section 2.3 explicitly covers relying parties using CAA. I believe that section should be removed, but it is in the current WG document.

As an individual (But of course "we're all individuals!":-)  [1]

I just had a read of this. Seems overly complicated to me by
quite a bit.

I think this should just define a way to nominate one or more
CAs as the chosen CAs for a domain and that's all.

What'd be wrong with looking up a domain and getting back an
RR with comma-sep list of strings representing the CAs that
the domain owner wants to use? The rest (and lots of the
language) just seems like useless complexity.

I don't even think we need to standardise on the name form
used - the CABforum people could agree on trademarks or
a FCFS list or whatever - its the issuing CA's responsibility
to know its own name(s) when it sees it(them), everything
else is unnecessary. (Including specifying the action when
the name(s) are not present.)

I think many of the MUST statements seem unnecessary, or
perhaps something that someone else (e.g. CABforum) could
define.

I agree with those who argue that the RP stuff doesn't
belong here, for technical, not turf-war, reasons. The main
reason is that if the RP is involved then we start to need
all the complex stuff since then it has to be well-defined.
Without the RP stuff, all we need is for CAs to recognise
themselves (or their absence) and all the rest can be
arranged out of band.

S.

[1] http://www.imdb.com/title/tt0079470/quotes

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Jun 2011 00:23:42 +0200 (MEST)

> tabloid journalism tactic.

I'm sorry if this term is offending to you, I really did not mean
to use it as an insult.  It characterizes a specific event that is
used to demonstrate a much more general problem with the trust
model that is used by TLS.

The Term Watergate wasn't used as an insult against the watergate
office complex, but instead as a reference to where it happened.
This particular event of misissued certificates could have
happened with any CA, not just Commodo.  But it happened at Commodo,
just like that other event happened at Watergate.

> Pejorative personal attacks and attacks against our employers are not

I refered to a particular event with a term that is quite commonly
understood to refer to that particular event, and described the
characteristics of the problems that this event showed up to have
always existed with the (lack of) trust anchor management in browsers.

I really did not intend to insult your employer, and I want to apologize
if you feel insulted.  What term would you prefer to refer to that
particular event so that everyone else recognizes it easily in
discussions?

> 1) PKIX must not intrude on what you define as DANE 'turf'

Nope, we just want to avoid confusion and needless complexity.
CAA should be for CAs and ignored by RPs, TLSA should be for RPs.

> certificate path validation mechanism.

I don't have the slightest clue what you are refering to.
rfc-2818 does not look like a product from PKIX, and rfc6125 was
no product of PKIX (it was discussed on an IETF mailing list called
certid).

> solve the issues you have identified.

It would be unusual for the IETF, after having newly chartered a new
working group to provide a solution, that shortly thereafter another
working group that has not previously workd on solutions for this
issue adopts a work item with the intent to compete with the new
working group.

> 4) The market should be allowed to decide whether your proposal is accepted.

Do you have a problem with that?

The event (whose name I'm not supposed to name) showed up which problems
exist with the "TLS X.509 PKI".  The CAs had their 15 years, now let
the IETF DANE WG build a solution and see whether the market
likes it.

> does the charter state that DANE is going to make statements about

Huh?

C'mon, you know that the most common wrapping for public keys is
X.509 certs, so it would be stupid not to support public keys
wrapped in X.509 certs in DANE, wouldn't it.  It also happens to
be a popular wrapping in other areas of the IETF.  Doing stuff
that fits together seems reasonable.

If the charter said "public keys wrapped in X.509 certs are out of scope"
that would be a different issue -- but as much as you would like that,
the DANE charter doesn't say that.

Your fear seems to be that DANE might obviate DV-validated certs
issued by CAs, because there is not much value proposition.
There should not be a tax on the use of TLS on the internet to
encrypt traffic, and DANE might help to provide "free licenses"
for the use of TLS.

-Martin

PS: I'm offline for the next couple of days

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 12 Jun 2011 21:00:51 -0400

> model that is used by TLS.

It was a pejorative term used by F-secure as an attack against one of their
competitors.

> just like that other event happened at Watergate.

Its the -gate suffix that is the problem here.

Comodo fraudulent certificate incident would be acceptable. Comodo nuclear
catastrophe, Comodogate etc not acceptable.

> CAA should be for CAs and ignored by RPs, TLSA should be for RPs.

We are not finished with the design of TLSA yet.

We seem to have agreement that there is a potential overlap. Is it really
beyond possibility that we can't agree on a common syntax?

I am quite happy to rev the syntax of CAA if that makes sense. But do
remember that the syntax there is chosen to match the syntax of PKIX

> Do you have a problem with that?

No, but that position is incompatible with the position 'nobody else allowed
to work in this area'.

> the IETF DANE WG build a solution and see whether the market

X.509 did not get a clear path.

When X.509 emerged the IETF was working on DNSSEC, SPKI and PGP all at the
exact same time.

> encrypt traffic, and DANE might help to provide "free licenses"

No, my fear is that the DANE group risks mucking up the best chance for
getting rid of them.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Jun 2011 08:51:08 -0700

> the name(s) are not present.)

This misses the point that these DNS records are going to be formed and put in by DNS admins. Asking a DNS admin to pick the right name form for the CA seems onerous. If we can instead say "the name comes from the cert you are using or the cert you want to be using, and here is how to extract it", that will lead to fewer false negatives where the DNS admin gets the desired name wrong.

Further, if we go with your proposal, we can't even say "get the name from the Subject or the SubjectAltName" because some CA have tortured these fields to death.

The current draft uses policy OIDs, which are completely unfamiliar to DNS admins, but at least you can get it from a CA cert you are holding. My preference would be a hash of the CA's public key, but I can also see some positive value to using the policy OID. However, I think "let the CAs pick names and somehow transmit them to the DNS admins" is not a good way to get interop.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jun 2011 18:05:05 +0100

> The current draft uses policy OIDs, which are completely unfamiliar to DNS admins, but at least you can get it from a CA cert you are holding. My preference would be a hash of the CA's public key,…

Well, you might be right...or not:-)

The relevant interop here (absent RPs using CAA) is that the
CAA RR just needs to include (or not) something an issuer
recognises as representing itself. If that's missing then
the issuer should fall back to special processing and not
just fire ahead and issue a cert.

I think that should be much less demanding than the usual
case where the issuer name has to be processed automatically
by RP code written by many other 3rd parties. In this case,
its only the issuer's own code that compares the value.

In particular, if the special processing is (I believe, but I
could be wrong) likely to involve a human, and if CAA is mostly
used by higher-value domains worried about bad or careless CAs,
then a relatively high proportion of false negatives won't
really be a problem. (And would likely lead to an issuer
choosing a new and less problematic value I expect.)

It *might* be easier to use something from a cert or trust anchor,
but I suspect that (in particular first time out) cut'n'paste
from the issuer's web page will be easier and maybe is what's
likely to actually happen, in which case, why not just let each
issuer choose what they want? I don't think accidental string
collisions here are a serious concern really. I'm also not at
all convinced that there's a security benefit in doing anything
computational for this value.

I'd be fine with those string values being OIDs, (in string
form), or DNs, or trademarks, or the date of birth of the CEO,
or a truncated hash of a public key or whatever. I think we can
just let the actual issuers choose this one.

It could be reasonable to say that the values MUST be at
least 8 bytes long and MUST NOT contain NULL or stuff like
that, but I don't see much of a need for anything else really.

But I don't think this is a huge point really, other than maybe
providing a welcome case where we can deliberately decide to choose
something much simpler than the usual sort of identifier needed
in a PKI.

However, it could equally be the case that I'm wrong about
the lack of security impact for some of this, but I've no doubt
that'll be thrashed on the list and we'll end up with something
that works.

Cheers,
S.

---

From: koichi sugimoto <[email-masked]>
Date: Wed, 15 Jun 2011 17:04:15 +0900

Dear Sirs,

Anyway, I do not feel good to use PKIX or IETF in order to attack
specific service like DV or
to benefit specific group.
If DANE or CAA purposes such a thing, then, the draft should be
removed from standards.
But it truely aims to reduce some security risks, it must be discussed
more costructive.
As for bit 6 of CAA, IMHO, it shuld be used as black list, not as white list.
If some certificate mis-issued by some CA, then, RP can block the certificate.
I think it might be more efficient than OCSP and CRL.

Regards,
Koichi Sugimoto.