Subject: Re: [dane] CAA: Isn't this completely backwards?

From: Stephen Schultze <[email-masked]>
Date: Wed, 1 Jun 2011 13:45:47 -0400

On May 30, 2011, at 8:48 AM, Peter Gutmann wrote:
> When I first heard of CAA I thought it was great, a web site owner  
> could
> indicate that only certificates from CA X should be trusted for  
> their site:
>
>  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.
> [...]

Right, and the following sentence is:
"Publication of CAA resource records allow a public Certification  
Authority (CA) to implement additional controls to reduce the risk of  
unintended certificate mis-issue."

So the obvious primary purpose is for communication between  
participating CAs, rather than to end users, which you observed...

> Then I saw things like:
>
>  Thus Relying Applications MUST NOT use failure to conform to  
> currently
>  published CAA records as a rejection criteria for certificates  
> unless [...]
>
> OK, so that's not a good start.  What's the intended use for this  
> then?  Let's
> see...
>
>  Examples of Use.
>
>  The following example informs CAs that certificates must not be  
> issued
>  except under [...]

So yes, it's backwards if what you're assuming it is intended to  
indicate anything to end users.  The current draft confuses things,  
because it *does* include discussion of relying parties... although  
seemingly as an afterthought.  I think the CAA authors should drop  
their section 2.3 and any other reference to relying party  
applications and instead focus their relying party energies on DANE --  
in particular the current draft's section 2.3 cert type 2.  That way  
we can all clearly address the issues together.  Paul suggested the  
same thingsix months ago:

http://www.ietf.org/mail-archive/web/dane/current/msg01316.html

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 01 Jun 2011 14:03:34 -0400

On Wed, 2011-06-01 at 13:45 -0400, Stephen Schultze wrote:
> The current [CAA] draft confuses things,  
> we can all clearly address the issues together.

I agree.  Current DANE supports server and CA certificate constraints,
while current CAA supports those and certification policy constraints
and could add new constraint types in the future.  Leaving aside the
extensibility, my feeling is that the certification policy constraints
may be useful for issuance, but I am not seeing a use case that would
benefit materially from having relying parties enforce certification
policy constraints rather than (say) CA certificate constraints.  So I
think Stephen's suggestion is appropriate.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Jun 2011 17:10:16 -0400

The reason CAA has the elements referring to client side enforcement is to
alert deployers and implementers to the fact that the criteria for issue and
enforcement are different. An existing certificate must be valid for use
even if the CA has lost its issue privileges.

So it is a bad idea to propose a specification that does not support both
use cases. Though in practice the need for ongoing relying party checks
should be quite small.

For example, imagine that we fix certificate revocation mechanisms such that
a browser provider can push out a blacklist of 'bad certificates' (i.e.
certs known to be actually dangerous). In that case it would be sufficient
for a small number of clients to do relying party checks and notify the
blacklisting mechanism if something untoward is seen.

As Peter says, CAA is backwards to the approach that people have been
attempting to use for years. But that might well be because we have been
approaching the problem backwards from the start.

I have also proposed merging the two approaches. However we have a serious
obstacle to achieving that.

My strong belief is that any IETF standard must be designed to interoperate
with other IETF standards. So I regard the following to be essential:

* 100% compatibility with all DNS features including wildcards, CNAME, DNAME
and SRV

* Use syntactic forms that are compatible with the protocols that it is
designed to interoperate with, i.e. PKIX

* Use algorithm identifiers that are compatible with the protocols that it
is designed to interoperate with.

Now people can claim that consensus in the WG is that this group has decided
to ignore all this and go off to do everything its own way. But that
approach tends not to go down too well in the rest of the IETF or the rest
of the industry.

So if the WG syntax turns out to be successful and people deploy I would
expect that a rev of CAA would be developed to align CAA with whatever is
deployed.

But if the IETF at large complains that DANE needs to be compatible with
existing IETF protocols then CAA and the other proposals I have made
represent a proof of existence of an alternative approach that does not
introduce unnecessary incompatibilities and inconsistencies as the Hoffman
et al draft does.

On Wed, Jun 1, 2011 at 1:45 PM, Stephen Schultze <[email-masked]> wrote:

>> When I first heard of CAA I thought it was great, a web site owner could
>> indicate that only certificates from CA X should be trusted for their
>> site:
>>
>>  DNS domain name holder to specify the certificate signing certificate(s)
> "Publication of CAA resource records allow a public Certification Authority
> (CA) to implement additional controls to reduce the risk of unintended
> certificate mis-issue."
>
> So the obvious primary purpose is for communication between participating
> CAs, rather than to end users, which you observed...
>
>
>  Then I saw things like:
>>
>>  Thus Relying Applications MUST NOT use failure to conform to currently
>>  published CAA records as a rejection criteria for certificates unless
>> [...]
>>
>> OK, so that's not a good start.  What's the intended use for this then?
>>  Let's
>> see...
>>
>>  Examples of Use.
>>
>>  The following example informs CAs that certificates must not be issued
>>  except under [...]
>>
>
> So yes, it's backwards if what you're assuming it is intended to indicate
> anything to end users.  The current draft confuses things, because it *does*
> include discussion of relying parties... although seemingly as an
> afterthought.  I think the CAA authors should drop their section 2.3 and any
> other reference to relying party applications and instead focus their
> relying party energies on DANE -- in particular the current draft's section
> 2.3 cert type 2.  That way we can all clearly address the issues together.
>  Paul suggested the same thingsix months ago:
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 13:05:52 -0400

On Wed, 2011-06-01 at 17:10 -0400, Phillip Hallam-Baker wrote:
> The reason CAA has the elements referring to client side enforcement
> is to alert deployers and implementers to the fact that the criteria
> for issue and enforcement are different. An existing certificate must
> be valid for use even if the CA has lost its issue privileges.
> 
> So it is a bad idea to propose a specification that does not support
> both use cases.

You are rather glibly coupling (1) the desire to discourage implementers
from misapplying the issuance constraints as relying party constraints
and (2) the potential utility of relying party constraints.  I think we
can all agree that in IETF protocol work, discouraging the
misapplication of a scheme for A to B is not grounds for introducing
dummy functionality for B.  Hence (1) is null and relying party
enforcement in CAA must stand on its own merits, in light of potential
overlap with DANE.

> I have also proposed merging the two approaches. However we have a
> serious obstacle to achieving that.
> 
> My strong belief is that any IETF standard must be designed to
> interoperate with other IETF standards. So I regard the following to
> be essential:
> 
> * 100% compatibility with all DNS features including wildcards, CNAME,
> DNAME and SRV 

DANE (TLSA) and SRV are not compatible, but composable: DANE comes into
play after SRV discovery is completed.  I consider compatibility with
wildcards and CNAME/DNAME to be essential for DANE too and just filed a
ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/24).  Are there
other relevant "DNS features"?

> * Use syntactic forms that are compatible with the protocols that it
> is designed to interoperate with, i.e. PKIX
> 
> * Use algorithm identifiers that are compatible with the protocols
> that it is designed to interoperate with.

CAA/DANE tools will be interoperable with one another no matter what
syntactic forms or algorithm identifiers are used.  What you are talking
about is homogeneity of design, not interoperability.  And AIUI, the
DANE group chose homogeneity with DNS over homogeneity with PKIX.  I
think this is appropriate in view of the possible future use of DANE
with non-PKIX TLS "certificate types".

-- 
Matt

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Jun 2011 18:16:18 +0100

So just a venue point - the PKIX WG have today agreed to
adopt CAA as a work item. When this has gone a bit further as
a work item there we'll be able to deal with any remaining
overlap with DANE more easily so I'd suggest moving
discussion on this to PKIX for the next while. (Well,
once Phill has posted a -00 PKIX WG document I guess.)

Cheers,
Stephen.

---

From: John Gilmore <[email-masked]>
Date: Thu, 02 Jun 2011 11:14:46 -0700

CAA seems like a complete abuse of the domain name system to
communicate a domain owner's restriction to CA's that are too lazy to
access the domain's web site (or look up the domain in WHOIS), pick up
the phone, and call the domain owner to verify that they really
ordered this alleged certificate.

Since that seems to be the state of the art in "certifying"... no
round-trip verification at all... why should we dignify that with an
otherwise useless DNS record, that by its own definition doesn't
communicate anything to anybody except a few hundred CA's worldwide?

	John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 14:34:25 -0400

> enforcement in CAA must stand on its own merits, in light of potential

I think that what we can all agree on is that it would be a good thing if
the DANE WG and the PKIX WG eventually arrive at a common view of the
problem as a whole.

> other relevant "DNS features"?

I agree that they need to be composable. But that does not necessarily mean
that they take place entirely independently or that DANE always follows SRV.

The reason is that I have been working on the problem of making wildcard
records work correctly with prefix records for some time and I think the fix
for the problem of SRV prefix records is the same as the one we should adopt
for DANE.

Basically the problem is that prefix records only work as expected when
applied to a canonical name.

The solution that looks most promising to me therefore is that a DNS record
should always take a prefix record or it should never take a prefix record
and that the discovery process should always begin with an unprefixed name.

When a DNS client attempts to resolve an unprefixed name the result will be
one of the following

1) The name does not resolve at all
2) The name is found to be canonical
3) The name was not canonical and is mapped to a canonical name

So either the resolution process will halt after the first resolution
attempt or there will be an unprefixed name to continue the resolution
process.

So what it comes down to is how you deal with the corner cases such as the
need to support finer grained constraints. At the moment DANE only supports
one level of granularity but the mechanism used to do so is broken because
it does not work with wildcards and aliases.

I think that when DANE is fixed to work with wildcards and aliases it is
going to be necessary to have a two phase approach as outlined above which
suggests a discovery strategy that has two levels of granularity so that
constraints can be specified at the domain level or the host/port level and
that the host/port level is only consulted in the cases where a site
determines it is necessary to use finer granularity.

> with non-PKIX TLS "certificate types".

Well I have been involved in SDSI/SPKI, PGP, XKMS and SAML which have all
attempted to play that game. Other than SAML I can't see that it was much of
a success and SAML only succeeded because it offers a completely different
value proposition. Most people don't even realize that the SAML assertion
structure is a generalization of PKIX.

In retrospect I now regret the fact that we effectively forked the algorithm
registry in XML Signature. We ended up creating a completely parallel set of
algorithm IDs to maintain when we could have simply reused the OID
assignments with the OID: URI type.

I believe that the correct way to view DANE is as part of the application
layer framework and that it should therefore adopt application layer
framework tropes. DANE has to work with the TLS and PKIX Working Groups. It
is probably not a good thing if it ends up having to have extensive
discussions with the DNS world. That would probably mean that there is
something wrong.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jun 2011 14:41:32 -0400

The issue is not laziness, the issue is being able to define a process that
is actionable in 150 different countries with a lot of different languages
and a lot of different legal systems.

I can call up the CSO of Sony to authenticate their cert request but there
is no guarantee that he is going to speak English. And even if he speaks
English there is no guarantee that he is going to have the slightest notion
of the existence of the project requiring the cert.

Working out whether an employee of a company incorporated in Japan with the
name Sony in the corporate name and a part of the Sony group is authorized
to request a certificate for sony.com is distinctly non trivial even for an
expert in Japanese law.

The objective here is not to solve all these issues. But we can help flag
the cases where there may be an issue.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 14:49:49 -0400

> ordered this alleged certificate.

That is a mischaracterization.  CAA can serve as an additional automated
check for CAs that use either automated (typically email-based) domain
control verification or manual verification, to catch mistakes in either
process and provide a level of accountability.

> communicate anything to anybody except a few hundred CA's worldwide?

Why shouldn't we?  The cost is minimal: another entry in the zone (which
clients will never be bothered about unless they ask) and another bit in
the NSEC.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 02 Jun 2011 15:20:52 -0400

On Thu, 2011-06-02 at 14:34 -0400, Phillip Hallam-Baker wrote:
> On Thu, Jun 2, 2011 at 1:05 PM, Matt McCutchen
> <[email-masked]> wrote:

> I think that what we can all agree on is that it would be a good thing
> if the DANE WG and the PKIX WG eventually arrive at a common view of
> the problem as a whole.

Yes, but I'm not holding my breath.  Some of us just want TLS server
authentication that is worth a ____.

My point that you quoted stands.
 
> I agree that they need to be composable. But that does not necessarily
> mean that they take place entirely independently or that DANE always
> follows SRV.
> 
> 
> The reason is that I have been working on the problem of making
> wildcard records work correctly with prefix records for some time and
> I think the fix for the problem of SRV prefix records is the same as
> the one we should adopt for DANE.

I agree that SRV and DANE should use the same approach.  That does not
entail using the same record, which would unnecessarily couple the
processes.  I prefer the current design with SRV before DANE for the
reasons I previously gave
(https://www.ietf.org/mail-archive/web/keyassure/current/msg01715.html).

> The solution that looks most promising to me therefore is that a DNS
> record should always take a prefix record or it should never take a
> prefix record and that the discovery process should always begin with
> an unprefixed name. [...]

The right place to discuss the details would be at
https://trac.tools.ietf.org/wg/dane/trac/ticket/24 .

> Well I have been involved in SDSI/SPKI, PGP, XKMS and SAML which have
> all attempted to play that game. Other than SAML I can't see that it
> was much of a success and SAML only succeeded because it offers a
> completely different value proposition. Most people don't even realize
> that the SAML assertion structure is a generalization of PKIX.

In my view, the reason PKIX/TLS succeeded is that the tools were widely
available and braindead easy: urlopen("https://hallambaker.com/").  And
DANE can be a drop-in replacement, as demonstrated by my prototype.

> In retrospect I now regret the fact that we effectively forked the
> algorithm registry in XML Signature. We ended up creating a completely
> parallel set of algorithm IDs to maintain when we could have simply
> reused the OID assignments with the OID: URI type.

Valid point.  But I don't see this becoming a major obstacle for DANE.

> I believe that the correct way to view DANE is as part of the
> application layer framework and that it should therefore adopt
> application layer framework tropes.

I don't follow this argument (not that I would strongly argue the
opposite either).  For a flippant example, MX records do not consist of
an RFC 822-format headers giving the host name and priority.

> DANE has to work with the TLS and PKIX Working Groups. It is probably
> not a good thing if it ends up having to have extensive discussions
> with the DNS world. That would probably mean that there is something
> wrong.

A scheme for TLS server authentication obviously has to work with TLS.
>From the perspective of DANE, the only claim to fame of PKIX is that it
was the first certificate type to be supported by TLS and is still
overwhelmingly the most popular.  Hence, I don't think design
homogeneity with PKIX should be a goal for parts of DANE that are not
PKIX-specific.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jun 2011 11:46:13 -0400 (EDT)

On Thu, 2 Jun 2011, Phillip Hallam-Baker wrote:

> The issue is not laziness, the issue is being able to define a process that is actionable in 150 different countries with a lot of different languages and a lot of different
> legal systems.
> I can call up the CSO of Sony to authenticate their cert request but there is no guarantee that he is going to speak English. And even if he speaks English there is no
> guarantee that he is going to have the slightest notion of the existence of the project requiring the cert.
> 
> Working out whether an employee of a company incorporated in Japan with the name Sony in the corporate name and a part of the Sony group is authorized to request a certificate
> for sony.com is distinctly non trivial even for an expert in Japanese law.

If only we could add a DNS record in our zone and sign it to signifiy what our pubkey is...

If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey
needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS
lookup of the pubkey.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 03 Jun 2011 17:30:47 -0400

> needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS

For those who want to support legacy clients while making the maximum
possible use of DNS, this is absolutely the thing to do, except I would
use the CSR or even (CSR, requested signer cert).  This is just to
authenticate the entire request; the CA may only honor a subset of the
CSR fields according to its policies.

Organizations that have a close relationship with a CA may not feel the
need to duplicate their requests to the CA in the DNS, but they may find
the ancestor cert and cert policy constraints to be useful controls.
Hence, I would keep those options as well.

Let's take further discussion of CAA to the PKIX list.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 03 Jun 2011 23:05:04 -0400

> CSR fields according to its policies.

Do you all realize what we'll be able to do with such a protocol?  Just
give your web server access to update its DNS data via TSIG, and it can
generate a key pair, poke the DANE records into DNS, and get itself a
domain-validated certificate from your favorite CA.  This functionality
could be in the TLS server library.  (Yes, Martin, I mean "TLS and
associated technologies".)

At a higher level, when you register a domain from $favorite_web_host,
you could check a box and have them set up the whole nine yards: DNSSEC
with DS submitted to the registry, TLS, DANE, a domain-validated
certificate, strict transport security, and whatever else we cook up.
Phill, this may be the "easy TLS adoption" you were looking forward to.

-- 
Matt