Subject: [keyassure] Certification Authority Authorization Draft.

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Oct 2010 17:32:12 -0400

This is a draft that I submitted this morning. The main proposal being made
here is to enable Certification Authorities to avoid mis-issue.

As such I believe that it is complimentary to mechanisms that enable client
side enforcement but has the considerable advantage of offering immediate
protection to every Internet user regardless of whether they have an updated
browser. It is also much less strongly dependent on deployment of DNSSEC.

http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt

Given the nature of the proposal, it is probably better suited to having the
bulk of the legal-technical work considered in CABForum rather than IETF.
Accordingly the proposal is designed to allow the technical infrastructure
to be agreed in IETF and then the practices and legal work done in CABForum.

Clearly a record of this type could be used to effect client policy
enforcement mechanisms. But this is a rather more complex issue and there
are going to be a lot of people with views on the best way forward.

The mechanism as specified is sufficient for allowing client side
enforcement as it stands if the site is using a public CA, running a local
CA cross certified into a public hierarchy or using a standalone private CA.
But only if those infrastructures are supporting all their applications
without exception.

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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Oct 2010 21:51:27 -0400

I have not yet read the whole draft, but so far I really like it. 

While (as you already pointed out) it doesn't solve all of the issues, it does go a long way towards improving matters, assuming of course the CAs buy in...

W
On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:

> This is a draft that I submitted this morning. The main proposal being made here is to enable Certification Authorities to avoid mis-issue. 
> 
> As such I believe that it is complimentary to mechanisms that enable client side enforcement but has the considerable advantage of offering immediate protection to every Internet user regardless of whether they have an updated browser. It is also much less strongly dependent on deployment of DNSSEC. 
> Given the nature of the proposal, it is probably better suited to having the bulk of the legal-technical work considered in CABForum rather than IETF. Accordingly the proposal is designed to allow the technical infrastructure to be agreed in IETF and then the practices and legal work done in CABForum.
> 
> Clearly a record of this type could be used to effect client policy enforcement mechanisms. But this is a rather more complex issue and there are going to be a lot of people with views on the best way forward.
> 
> The mechanism as specified is sufficient for allowing client side enforcement as it stands if the site is using a public CA, running a local CA cross certified into a public hierarchy or using a standalone private CA. But only if those infrastructures are supporting all their applications without exception.
> 
> 
> -- 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Oct 2010 22:17:04 -0400

Adam L. pointed out some typos and so on. I had to get it in today and I am
fighting off a cold.

As we discussed in the call, we are very interested in having Google
co-author if you are interested.

CA buy-in is not so much of a worry for me. Comodo will deploy for certain
and Symantec/VeriSignCA is pretty likely to follow.

Assume for a moment that other CAs don't follow our lead and end up
mis-issuing against a domain that has a CAA record. What do you think their
liability is in that case? They certainly have a major PR issue at that
point and their only realistic chance of surviving it without too much
damage is going to be to deploy CAA.

So all in all, I think that the chances are pretty good that we can present
this as a win for all concerned.

You may also be interested in my DPLS draft:

http://www.ietf.org/id/draft-hallambaker-dpls-00.txt

A lot of the DNS performance issues go away if the DNS client can ask its
resolver 'hey give me all the info I need to do this with that'.

On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <[email-masked]> wrote:

> While (as you already pointed out) it doesn't solve all of the issues, it
> does go a long way towards improving matters, assuming of course the CAs buy
> in...
>
> W
> > This is a draft that I submitted this morning. The main proposal being
> made here is to enable Certification Authorities to avoid mis-issue.
> >
> > As such I believe that it is complimentary to mechanisms that enable
> client side enforcement but has the considerable advantage of offering
> immediate protection to every Internet user regardless of whether they have
> an updated browser. It is also much less strongly dependent on deployment of
> DNSSEC.
> > Given the nature of the proposal, it is probably better suited to having
> the bulk of the legal-technical work considered in CABForum rather than
> IETF. Accordingly the proposal is designed to allow the technical
> infrastructure to be agreed in IETF and then the practices and legal work
> done in CABForum.
> >

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 Oct 2010 16:28:09 -0400 (EDT)

> http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt

    The Certification Authority Authorization (CAA) DNS Resource Record
    allows a DNS domain name holder to specify the certificate signing
    certificate(s) authorized to issue certificates for that domain.

If you can trust the CAA DNS record, why could you not trust a record
with SSL/TLS FP from the same administrative source? From a technical
point of view, this record makes no sense.

This record seems to address practical limitations of the CA trust model,
whereby one installed omnipotent CA could make a claim contradicting
another omnipontent CA.

> Clearly a record of this type could be used to effect client policy enforcement mechanisms.

A better fix would be to replace/fix the broken bag of omnipotent CA's
endusers now have to blindly trust. If that solution is sought outside
the scope of CA's and X.509, CRLs, OCSP's etc, then it makes no sense to
keep lingering in that space, and instead just move on to DNSSEC based
trust relationships.

    Before issue of a certificate a compliant CA MUST check for
    publication of a relevant CAA Resource Record and if a record is
    published that the certificate requested is consistent with it.  If
    the certificate requested is not consistent with the CAA RR
    authorization, the CA MUST NOT issue the certificate.

This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what's
left of the role of the CA?

If the CAA DNS record would present a migration path from CA's to DNSSEC
based authentication, I might see a use for it.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 Oct 2010 16:44:55 -0400 (EDT)

On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:

> Assume for a moment that other CAs don't follow our lead and end up mis-issuing against a domain that has a CAA record. What do you
> think their liability is in that case? They certainly have a major PR issue at that point and their only realistic chance of
> surviving it without too much damage is going to be to deploy CAA.

Seeing that rapidssl is still very much alive, I think we can safely say PR is not a valid detergend
against running an uhm, less then optimally secure CA.

> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt

A quick peek:

    DPLS allows for more efficient secure DNS resolution by enabling a
    trusted resolver to efficiently authenticate communiction with a
    client.

I doubt the impact of running DNSSEC on the enduser is that much
of an impact these days. Especially because of DNS caching. Plus,
if efficiency is an issue, configuring the enduser to use a trusted
validating usptream resolver addresses that problem too (except it would
not have confidentiality, but see below)

    A secondary advantage of using DPLS is that it enables traffic
    between the DNS client and resolver to be encrypted, thus reducing
    exposure to confidentiality attacks.

It might protect last-mile wifi confidentiality attacks, but nothing
else. Because it is easy to give unique DNS labels to clients for tracking
purposes, unless hundreds+ clients are all congregating their traffic
at a common DNS server (something that TOR tries to do)

> A lot of the DNS performance issues go away if the DNS client can ask its resolver 'hey give me all the info I need to do this with
> that'.

Those can be done using EDNS options as well.

the draft discusses a lot of split DNS setups and required confidentiality, but
that all boils down to "enterprises need VPN + company DNS server". I am unclear
how this draft would change that, except adding some new kind of transport layer
security. If one would design something like that, the very least I would expect
is a way to return more data to the client in bulk that it will encounter when
doing more queries anyway. Latency is the performance issue here, not bandwidth
or CPU usage.

Paul
Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 24 Oct 2010 17:48:32 -0400

CAA only requires deployment by two parties to be useful and provide
coverage, both of which are highly motivated to act.

TLSFP requires the client application to be upgraded before a relying party
has any protection. That means that deployment will take a minimum of ten
years. It also means that it is a good deal harder to get right.

There is a good case to be made for client side enforcement of certificate
issuing policy, but it is not a substitute for better issue controls.

As for reducing the number of CAs, that is rather more difficult than you
might imagine. CAA is designed to set an objective test that gives a browser
provider grounds for withdrawing accreditation.

There is no magic in the choice of bits on the wire. DNSSEC suffers from
exactly the same set of issuing chain difficulties as PKI does. The number
of DNS registrars is actually considerably larger than the number of SSL
validation authorities.

On Sun, Oct 24, 2010 at 4:28 PM, Paul Wouters <[email-masked]> wrote:

>> enforcement mechanisms.

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 25 Oct 2010 11:36:59 +0200

On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote:

> There is no magic in the choice of bits on the wire. DNSSEC suffers from exactly the same set of issuing chain difficulties as PKI does. The number of DNS registrars is actually considerably larger than the number of SSL validation authorities. 

Except that it is apparent for the victim when a DNS registrar goes rogue (as the result is published in the DNS), whereas a trusted CA can issue bad certificates without detection.

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 08:01:29 -0400

Not necessarily.

If the registrar is defecting they can change the DNS, look for the update,
ping the resolver whose cache they want to poison and then reverse out the
changes once the cache is poisoned.

If you make equivalent assumptions, both systems are vulnerable to
compromise. The only way you can do better is if you use both systems and
check both paths so that you get some degree of separation of duties.

On Mon, Oct 25, 2010 at 5:36 AM, Jakob Schlyter <[email-masked]> wrote:

> Except that it is apparent for the victim when a DNS registrar goes rogue
> (as the result is published in the DNS), whereas a trusted CA can issue bad
> certificates without detection.
>
>        jakob
>
> --
> Jakob Schlyter
> Kirei AB - www.kirei.se
>
>

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 25 Oct 2010 14:33:14 +0200

On 25 okt 2010, at 14.01, Phillip Hallam-Baker wrote:

> If the registrar is defecting they can change the DNS, look for the update, ping the resolver whose cache they want to poison and then reverse out the changes once the cache is poisoned.

Only the registrar you have chosen can go rogue. If you don't trust your registrar, chose another one. Compared to legacy PKI, where you can cannot choose as all CA:s are trusted without constraints, this is a huge win.

I do agree that combining DNSSEC and EV is even better. However, combining DNSSEC and DV to order to increase security is IMHO close to useless.

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 09:31:55 -0400

That has yet to be established.

In theory that should be the case. In practice the transfer of dns names is rather more complex. I have been trying to find documentation on the controls. They may not be public or they may not exist. 

If you want to demonstrate that one system is more secure than the other you have to apply the same standard of scruitiny to both systems. 

Sent from my iPad

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Oct 2010 12:36:31 -0400 (EDT)

> If you want to demonstrate that one system is more secure than the other you have to apply the same standard of scruitiny to both systems.

The same applies for chaining security systems (DNSSEC and CA's).

I remember when crpytophone people did not trust one cipher, and Rudi
Weiss had to prove that (AES->3DES->blowfish) was at least as secure as
the weakest component in that list. Which he did in a paper that went
beyond my math skills.

Entangling CA's and DNSSEC would need some proof that it is more secure
then its individual components. With some strong weaknesses in the CA
deployments and omnipotent trust wielders, I am extremely skeptical
this can be done. And the price to pay is to deal with many corner
cases because unlike chained chiphers, this entangled system would not
have a clear serial flow through it. Contradictions would be possible,
and then we run into many interpretations and implementations as to how
to address these.

The reason (IMHO) that we are doing anything in the ASN.1 space at all
for DNSSEC is that we have to deal with X.509 in SSL/TLS.

But I think this discussion has already been seen on this list various
times, so I'll refrain from further firing up this discussion *again*

Paul

---

From: Ben Laurie <[email-masked]>
Date: Mon, 25 Oct 2010 17:47:51 +0100

Sorry for the delay..

Looking at the -01 version...

"The authorizations specified in the dauth and pauth properties are
   additive."

I'm not sure "additive" is the right word - certainly it leaves me
wondering "does that mean 'and' or 'or'?". Later text confirms "or",
which was not my guess.

Why restrict tag length in the CAA RR?

"An ASN.1 DER encoded data field containing the digest value of the
      referenced object processed using the specified digest algorithm."

I don't think this is an unambiguous specification - you have to
specify the ASN.1...

"   Use of DNSSEC to authenticate CAA RRs is strongly recommended but not
   required.  A CA MUST observe a CAA RR that is returned whether it is
   signed using DNSSEC or not."

Fine - but I think it should say that applications MUST NOT observe a
CAA RR that is not signed.

4.2 should note that DNSSEC effectively prevents either suppression or spoofing.

Other than that, looks good to me.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 13:36:49 -0400

> wondering "does that mean 'and' or 'or'?". Later text confirms "or",

I had difficulty drafting that. I think that the problem is that I should be
using the term 'permission' or 'authorization entry'.

> Why restrict tag length in the CAA RR?

The tags are from an assigned space. The only protocol constraint I would
really insist on is that the tag length needs to be expressible in a single
byte.

Do we really think we will need more than 2^16 different tags in a data
record that has to fit into a 65535 byte space?

> I don't think this is an unambiguous specification - you have to

I am not sure what point you were going to make here.

I am sure that there can be some byte sex issues that enter into things
here.

Some digest algorithms have more than one OID assigned. But the ones we
currently recommend in IETF specs have exactly one OID assignment across all
specifications, the one assigned by NIST. And this should be the same for
the SHA-3 algorithms as well.

One other point that was raised was that some people would like to have the
ODI data wrapped in an ASN.1 tag, length container as well.

> CAA RR that is not signed.

OK, that is fair enough.

I am thinking that we may want to differentiate between authority to issue
and authority for relying parties.

The issue authority statements refer to what an issuer is authorized to do
during the validity interval for the record.

But the fact that an issuer is no longer authorized to issue new
certificates does not invalidate the certificates they have already issued.
So the statement for relying parties may well contain more entries.

> Other than that, looks good to me

That must have got lost in the editing.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Oct 2010 10:34:40 +0200

On 25.10.2010 11:36, Jakob Schlyter wrote:
>> There is no magic in the choice of bits on the wire. DNSSEC suffers
>> from exactly the same set of issuing chain difficulties as PKI
>> does. The number of DNS registrars is actually considerably larger
>> than the number of SSL validation authorities.
>
> Except that it is apparent for the victim when a DNS registrar goes
> rogue (as the result is published in the DNS), whereas a trusted CA
> can issue bad certificates without detection.

And many registries implement lock-down function, where you can tie your 
domain name to current registrar and prevent all transfers.  Some 
registries do it on the registry level[*] and I know I could lock at 
least some gTLDs via my registrar.  If there is need on higher 
protection from rogue registrars then more registries could implement 
lock-down function.

So your current sponsoring registrar would have to go wild.  But you are 
not protected in that case even nowadays.  (Issuing DV certs on 
whois/DNS data...)  (And some registrars have even direct channel with 
some CAs.)

Ondrej
* - http://www.nic.cz/whois/publicrequest/
-- 
  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: Ben Laurie <[email-masked]>
Date: Wed, 27 Oct 2010 10:05:01 +0100

> record that has to fit into a 65535 byte space?

No, I just wondered what the point of the restriction was. Perhaps you
want to reserve the other 4 bits for flags (e.g. it occurred to me
that marking permissions as critical might serve some purpose)?

> I am not sure what point you were going to make here.

I mean you should say how it is encoded (that is, as an OCTET STRING).

> I am sure that there can be some byte sex issues that enter into things

I hope not!

> the SHA-3 algorithms as well.

I'm talking about the digest itself, not the OID.

> ODI data wrapped in an ASN.1 tag, length container as well.

Seems not unreasonable - in which case the tag would be OBJECT IDENTIFIER.

> So the statement for relying parties may well contain more entries.

Excellent point.