Subject: [pkix] CAA record location / tree climbing

From: Richard L. Barnes <[email-masked]>
Date: Wed, 18 Jul 2012 09:37:34 -0400

Dear PKIX,

PHB: Thanks for all the changes you made in draft-ietf-pkix-caa-11.  I think this version is close to ready.

The one issue that I didn't feel we really got resolution on was the question of where CAA records should be located.  I still think the tree-climbing algorithm is confusing and likely to lead to subtle errors.  And the document still doesn't address the wildcard case.  

I have listed a complete set of proposed changes below.  The high-level outline is: 
-- A issuer looks for CAA records only at the name to be included in the certificate.  
-- If there are one or more CAA records present, then any issuance MUST comply with them.  
-- If there is no CAA, then the CAA system provides no information; an issuer MAY issue, subject to its local policy.  
-- If the name to be issued is a wildcard, then the issuer replaces the "*" with the label "_star" and uses the normal procedure.
-- Tree climbing is still allowed to find "iodef" records (with "MAY" strength).

This simplified procedure provides the same functionality as the current document with much simpler processing; the only cost is that CAA records have to be provisioned at individual domain names that are getting certificates.

I would like to get the WG's feedback on this proposal before we consider CAA finished.

Thanks,
--Richard

-----BEGIN Proposed Changes-----
Section 1.2:
OLD:
"
   Extended Issuer Authorization Set:  The most specific Issuer
      Authorization Set that is active for a domain.  This is either the
      Issuer Authorization Set for the domain itself, or if that is
      empty, the Issuer Authorization Set for the corresponding Public
      Delegation Point.
"
NEW:
""

Section 2.1:
OLD:
"
   Since the policy is published at the
   Public Delegation Point, the policy applies to all subordinate
   domains under example.com.
"
NEW:
""

Section 2.1:
OLD:
"
   If the domain name holder specifies one or more iodef properties, a
   certificate issuer MAY report invalid certificate requests to that
   address.
"
NEW:
"
   If the domain name holder specifies one or more iodef properties, a
   certificate issuer MAY report invalid certificate requests to that
   address.  Parties seeking to submit IODEF data MAY search for CAA
   records containing the "iodef" tag in superior nodes to the affected
   node in the DNS hierarchy, up to the closest Public Delegation Point.
"

Section 3:
OLD:
"
   The Issuer Authorization Set for a domain name consists of the set of
   all CAA Authorization Entries declared for the canonical form of the
   specified domain.
"
NEW: After "CAA Authorization Entries declared for the canonical form of the specified domain/"
"
   If the certificate to be issued is a wildcard certificate, then the 
   CA MUST replace the "*" character in the wildcard domain with the 
   label "_wildcard" before searching for CAA records.  For example, 
   before issuing a certificate for "*.example.com", the CA would check
   for CAA records under the canonical form of the name 
   "_wildcard.example.com".
"

Section 3:
OLD:
"
   The Extended Issuer Authorization Set for a domain name is determined
   as follows:

   o  If the Issuer Authorization Set of the domain is not empty, the
      Extended Issuer Authorization Set is the Issuer Authorization Set
      of the domain.

   o  If the immediately superior node in the DNS hierarchy is a Public
      Delegation Point, the Extended Issuer Authorization Set is empty.

   o  Otherwise the Extended Issuer Authorization Set is that of the
      immediately superior node in the DNS hierarchy.

   For example, if the zone example.com has a CAA record defined for
   caa.example.com and no other domain in the zone, the Issuer
   Authorization Set is empty for all domains other than
   caa.example.com.  The Extended Issuer Authorization Set is empty for
   example.com (because .com is a Public Delegation Point) and for
   x.example.com.  The Extended Issuer set for x.caa.example.com,
   x.x.caa.example.com, etc. is the Issuer Authorization Set for
   caa.example.com.
"
NEW:
""

Section 3:
OLD:
"
   If the Extended Issuer Authorization Set for a domain name is not
   empty, a Certification Authority MUST NOT issue a certificate unless
   the certificate conforms to at least one authorization entry in the
   Extended Issuer Authorization Set.
"
NEW:
"
   If the Issuer Authorization Set for a domain name is not empty, a
   Certification Authority MUST NOT issue a certificate unless the
   certificate conforms to at least one authorization entry in the
   Issuer Authorization Set.

   If the Issuer Authorization Set for a domain name is empty, then 
   CAA provides no information regarding certificate issuance.  In 
   this case, CAs MAY rely on alternative procedures for verifying
   the domain holder's authorization to issue a certificate.
"

Section 3.1:
OLD: "corresponding extended issuer authorization set"
NEW: "corresponding Issuer Authorization Set"

-----END Proposed Changes-----

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jul 2012 07:36:17 -0700

> I would like to get the WG's feedback on this proposal before we consider CAA finished.

Richard's proposed changes all seem fine. However, the current document seems OK as well. I would be OK with deploying as it is currently written and, if Richard is correct, fixing the protocol later. If the WG wants to hone it now, though, I think Richard's proposal is less confusing than the current tree-walking wording.

--Paul Hoffman

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 19 Jul 2012 00:52:55 +1000

> The one issue that I didn't feel we really got resolution on was the
> question of where CAA records should be located.  I still think the
> tree-climbing algorithm is confusing and likely to lead to subtle
> errors.  And the document still doesn't address the wildcard case.
> 
> -- If there is no CAA, then the CAA system provides no information; an
> issuer MAY issue, subject to its local policy.
> -- If the name to be issued is a wildcard, then the issuer replaces the
> "*" with the label "_star" and uses the normal procedure.
> This simplified procedure provides the same functionality as the
> current document with much simpler processing; the only cost is that
> CAA records have to be provisioned at individual domain names that are
> getting certificates.
> 

These changes would still allow Example Org to prevent compliant CAs from issuing certificates for, say, www.example.org and example.org (with 2 CAA records (or 3)). However, it makes it very hard (or impossible with DNSSEC?) to prevent certificates being issued for (non-existent) sub-domains (eg a3323422.example.org). That is bad as browsers give sub-domains some authority with respect to their parent domains. For instance, a sub-domain can often read cookies set by a parent domains (not sure if this is affected by a cookie's "secure" flag). A sub-domain is often in the same "security zone" for other browser security controls.

So I believe these changes would weaken CAA, not provide the same functionality.

--
James Manger

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 19:58:36 -0400

+1

I have not seen any argument for changing the spec other than that
someone thinks it would be 'simpler'.

The proposed change would weaken the specification and must be rejected.

On Wed, Jul 18, 2012 at 10:52 AM, Manger, James H
<[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

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

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Jul 2012 02:14:12 +0200 (CEST)

> someone thinks it would be 'simpler'.

The difference here is that I do understand Richards text immediately
on the first read, while I do have significant difficulties to read
the current Section 3 on processing of -11.
 
> The proposed change would weaken the specification and must be rejected.

My confusion with the current text in the I-D is sufficiently severe,
that I'm unable to figure out its meaning (at 2am) and the exact
differences to the proposed replacement text.

What is obvious though, is that the -11 draft does not say anything
about "wildcard" certs, and that looks like a real  defect to me.

-Martin

---

From: Mark Ennis <[email-masked]>
Date: Thu, 19 Jul 2012 10:28:43 +1000

Richard,

I would recommend changing your proposal to require that a CA that uses 
CAA will not issue certificates for domains without an associated CAA 
record. Your third outline point suggests this is a local policy decision.

Without such a requirement, I agree with James Manger's argument that 
your proposal is weaker than that proposed in the original text.

- Mark.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Jul 2012 14:20:23 -0400

> These changes would still allow Example Org to prevent compliant CAs from issuing certificates for, say, www.example.org and example.org (with 2 CAA records (or 3)). However, it makes it very hard…

First of all, if the policy is to look only at the leaf and require CAA, then a CA will never issue a cert for a non-existent domain because there won't be a CAA record there.

If you're worried about CAs that fall back to something else if CAA isn't present, couldn't the parent zone holder just set a wildcard that provides null CAA for any subordinate zone?  

*.example.com CAA 0 issue ";"

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Jul 2012 14:23:54 -0400

The authorization decision is ultimately always the CAs.  A CA could even choose to ignore the "MUST NOT issue contradicting CAA", if something in its CP told it to.

However, I would be comfortable revising the third bullet to something like the following:
-- If there is no CAA, then the CAA system provides no information; an issuer SHOULD NOT issue unless its Certificate Policy allows an alternative mechanism for validating domain holders

Is that better?

--Richard

On Jul 18, 2012, at 8:28 PM, Mark Ennis wrote:

> Richard,
> 
> I would recommend changing your proposal to require that a CA that uses CAA will not issue certificates for domains without an associated CAA record. Your third outline point suggests this is a local policy decision.
> 
> Without such a requirement, I agree with James Manger's argument that your proposal is weaker than that proposed in the original text.
> 
> - Mark.
>

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Jul 2012 20:37:48 +0200 (CEST)

Richard L. Barnes wrote:
> The authorization decision is ultimately always the CAs.
> A CA could even choose to ignore the "MUST NOT issue contradicting CAA",
> if something in its CP told it to.
> 
> -- If there is no CAA, then the CAA system provides no information;
>    an issuer SHOULD NOT issue unless its Certificate Policy allows
>    an alternative mechanism for validating domain holders
> 
> Is that better?

To me, that is backwards from what it should be.

The above implies that EVERY CA out there will have to update its CP
to say "we do not require CAA to be present as a prerequisite to issue
a cert for a domain", although such CAs are actually not changing their
CP at all.

Those who are changing their CPs are CAs that suddenly start looking at
or requiring CAA, and it is those CAs where the CPs should be augmented
to spell out that policy change.

  If there is no CAA, then a CA, which issued certs under a policy that
  requires CAA to be present, will not issue a certificate in absence of CAA.

CA's CPs and CABrowser Forum's "Baseline Requirements for the Issuance
and Management of Publicly Trusted Certificates" are the place for
defining/describing policy.  The CAA document should be limited to
describe technical function.

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Jul 2012 14:46:10 -0400

> a cert for a domain", although such CAs are actually not changing their

I think you've got it backwards.  Right now, *every* CA's CP allows an alternative mechanism for validating domain name holders, since CAA doesn't exist.

The question is what happens when you update your CP to account for CAA.  I think the goal is to  that if you have a CP that says "We require CAA", then the above SHOULD NOT turns into a MUST NOT.  But it should also be consistent with the RFC to have a CP says, "If CAA is present we follow it, otherwise we use our old process".

>  requires CAA to be present, will not issue a certificate in absence of CAA.

This seems like a tautology?

> describe technical function.

Regardless of what the spec says, there will be CPs that can conflict with it.

An example of a CP that is not consistent with the spec would be something like "If CAA is present but doesn't list us, then we will issue if the applicant provides his driver's license."  That would count as non-compliance with the standard.

--Richard

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Jul 2012 20:58:48 +0200 (CEST)

Richard L. Barnes wrote:
> Martin Rex wrote:
> I think you've got it backwards.  Right now, *every* CA's CP allows
> an alternative mechanism for validating domain name holders,
> since CAA doesn't exist.

Actually, we're currently both somewhat in the woods.  ;-)

CAA is definitely *NO* "mechanism to validate domain holders",
so even with CAA, every CA will have to use a "mechanism to validate
domain holders" that is not described in the CAA document.

CAA is a mechanism to "publish issuers considered acceptable by the domain
holder when processing CSRs".  In addition to that, it conveys information
through DNS, which is typically out-of-band from CSR submission, and could
be additionally protected by DNSSEC, about whether and whom to notify about
issuance of a certificate for a domain name.

-Martin

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 20 Jul 2012 12:11:00 +1000

Richard,

>> These changes would still allow Example Org to prevent compliant CAs
>> from issuing certificates for, say, www.example.org and example.org
>> (with 2 CAA records (or 3)). However, it makes it very hard (or
>> impossible with DNSSEC?) to prevent certificates being issued for (non-
>> existent) sub-domains (eg a3323422.example.org). That is bad as
>> browsers give sub-domains some authority with respect to their parent
>> domains. For instance, a sub-domain can often read cookies set by a
>> parent domains (not sure if this is affected by a cookie's "secure"
>> flag). A sub-domain is often in the same "security zone" for other
>> browser security controls.

> First of all, if the policy is to look only at the leaf and require
> CAA,

But that is NOT going to be the policy.
The policies will be (I hope):
* Firefox/Chrome/Opera/Windows/Safari/Java/... say a CA MUST implement CAA to be in the default list of trusted roots for that browser/OS/app (by, say, 2013)
* Relying parties curating their own trust list prefer to pick CAs that implement CAA
* Sites (particularly major ones) start to publish CAA records for their domains
* CAs continue to issue certs to sites that don't publish CAA records as they do today

> then a CA will never issue a cert for a non-existent domain
> because there won't be a CAA record there.
>
> If you're worried about CAs that fall back to something else if CAA
> isn't present,

I expect CAs to fall back like that.
I want CAA to be effective with that CA behaviour.
That CA behaviour should not undermine sites that do publish CAA records. 

>  couldn't the parent zone holder just set a wildcard that
> provides null CAA for any subordinate zone?
> 

I doubt that is sufficient. I might work for some non-existent domains (with lots of subtleties/glitches/exceptions according to http://en.wikipedia.org/wiki/Wildcard_DNS_record).

To make a.b.example.com safer, I don't want any CA other than CA1 to issue a certificate that browsers will accept as having any special permissions with respect to a.b.example.com (eg masquerade as, read cookies…).

Hence I want to publish CAA records so that CA2 will NOT issue a certificate for a.b.example.com, or *.b.example.com, or *.example.com, or nonexistent.a.b.example.com, or staging.a.b.example.com.

I don't think this can work if CA2 only looks for a CAA record in the domain it is being asked to certify. I would at least have to publish a CAA records for a.b.example.com, b.example.com, example.com, staging.a.b.example.com and every other subdomain that exists, and for *.… wildcard versions of each of these, and I am not that confident that that would be sufficient.

In contrast, if CA2 walks up the DNS to example.com until it finds a CAA record, then I can publish 1 CAA record at example.com to achieve my aim. I can optionally publish CAA records at b.example.com and/or a.b.example.com for some more specialised control.

--
James Manger

---

From: Carl Wallace <[email-masked]>
Date: Thu, 19 Jul 2012 22:17:21 -0400

>* Firefox/Chrome/Opera/Windows/Safari/Java/... say a CA MUST implement
>CAA to be in the default list of trusted roots for that browser/OS/app
>(by, say, 2013)

This will not happen until it becomes easy to change the trust posture of
a browser, i.e., to use a small TA set along the lines of what you suggest
for some actions and a broader set to access other sites for which the
user has less strict or no security requirements.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Jul 2012 22:37:57 -0400

Hi,

I know I'm late to the party, but I'm curious about something.

> Hence I want to publish CAA records so that CA2 will NOT issue a certificate for a.b.example.com, or *.b.example.com, or *.example.com, or nonexistent.a.b.example.com, or staging.a.b.example.com.

What makes you sure that example.com ought to be the people you ask
about what a.b.example.com is doing?  Is this just because you think
com is the last "public" registration point?  (Note, I say
"registration", not "delegation".  There's no reason, AFAICT, that
delegation is the relevant question here, but I may well be missing
something.  I have a draft floating around about this problem.)  If
so, how do you know that?  What if you're wrong?
 
> In contrast, if CA2 walks up the DNS to example.com until it finds a
> CAA record, then I can publish 1 CAA record at example.com to
> achieve my aim.

Quite apart from the tree-climbing problem, you can only do that if
you also know where the administrative boundaries are, and I don't
think you do.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Jul 2012 23:04:17 -0400

On Fri, Jul 20, 2012 at 12:11:00PM +1000, Manger, James H wrote:
> 
> To make a.b.example.com safer, I don't want any CA other than CA1 to
> issue a certificate that browsers will accept as having any special
> permissions with respect to a.b.example.com (eg masquerade as, read
> cookies…).
> 
> Hence I want to publish CAA records so that CA2 will NOT issue a
> certificate for a.b.example.com, or *.b.example.com, or
> *.example.com, or nonexistent.a.b.example.com, or
> staging.a.b.example.com.

Sorry for the second followup, but I have a sneaking suspicion that
I'm about to fall into the crack between what the DNS means by
wildcards, and what CAs appear to have meant.  Let me try to describe
issues I see, and you can tell me how I'm wrong.

a.b.example.com: this one's easy.  If it exists, put a CAA there.  If
it does not, NXDOMAIN, so no answer.

*.b.example.com: this is trickier.  I _think_ the problem you're
actually worried about is not that there is a zone entry for
*.b.example.com (which entails a.b.example.com gets an answer), but
rather that the CA might issue for *.b.example.com, and that would
cover the existing a.b.example.com, and you don't want that.  If I'm
right about this, then my earlier note about putting a CAA at the
wildcard entry indeed does not work: the semantics of "*" are not the
same between the DNS and the CA issuers, for better or worse, and
we're trying to give instructions to issuers.  Now I get this.

If that's the thing we're trying to talk about, then yes, you need
some special label to call this out.  I guess Richard's
underscore-convention answer (much as I hate those things) is as good
an answer as any other, then.

One other answer, of course, would be to make the issuance of wildcard
certs incompatible with CAA processing.  If you do CAA, you don't
issue wildcards, period, because they can't be tested properly in the
DNS.  I suspect this suggestion to fly like a lead balloon, but it
seems worth pointing out for completeness.

I note that nonexistent.a.b.example.com is an easy case in the face of
DNSSEC: you get a proof of non-existence, so you can know that there's
no such name and therefore you don't issue to it.  Right?

I still think, however, that tree-climbing is going to fall down
(sorry) because of the lack of information about where the
administrative boundaries actually are.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 20 Jul 2012 13:13:11 +1000

> certificate for a.b.example.com, or *.b.example.com, or *.example.com,
> or nonexistent.a.b.example.com, or staging.a.b.example.com.
> >
> 
> about what a.b.example.com is doing?

When I browse to https://a.b.example.com/ my browser address bar shows "a.b." in grey and "example.com" in bold; javascript from that site can set document.domain to "example.com", but not to "com"; etc. This tells me where the browser draws the security barrier, which is precisely where I want to restrict certificate issuance.

>  Is this just because you think

If a browser gets it wrong, or 2 browsers are inconsistent, then it might be awkward for domains in those corner cases to deploy CAA controls as effectively. Slightly annoying, but CAA still improves security for the other 99.9% of domains.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 20 Jul 2012 13:38:33 +1000

> cover the existing a.b.example.com, and you don't want that.

Yes, that is the worry.

>  If I'm

Or the CAA rule could be: a CA must not issue a wildcard cert for *.example.com unless it is allowed to issue a cert for example.com. Then you don't need any extra CAA records. Or define a ";wildcard=yes|no" parameter for the CAA record.

> seems worth pointing out for completeness.

Requiring CAs to ditch any wildcard-cert business to be CAA-compliant might hurt adoption ;)

> no such name and therefore you don't issue to it.  Right?

Wrong? It proves there is no CAA record to prevent cert issuance. It proves there is no name today, but perhaps you are waiting until you have the cert before launching. Perhaps some CAs require a DNS entry to exist as part of validating a cert request, but that is a separate issue from CAA.

--
James Manger

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jul 2012 00:28:12 -0400

On Fri, Jul 20, 2012 at 01:13:11PM +1000, Manger, James H wrote:
> 
> When I browse to https://a.b.example.com/ my browser address bar
> shows "a.b." in grey and "example.com" in bold; javascript from that
> site can set document.domain to "example.com", but not to "com";
> etc. This tells me where the browser draws the security barrier,
> which is precisely where I want to restrict certificate issuance.

I see.  Why do you believe that?

That display is based on a heuristic.  They use the list from
publicsuffix.org, and decide that that's the place that counts.  It's
a pretty good rule of thumb, but it breaks in some corner cases.  My
experience in talking to browser manufacturers is that this is a good
enough approximation from their POV, even though they know it's
imperfect.

Importantly, if b.example.com delegates a.b.example.com to someone
else (which they are free to do), the thing you have described means
that the operator of a.b.example.com is now subject to the controls at
example.com (or wherever the CAA is) whenever they don't know about
that CAA record.  Maybe we don't care, but I think we better
understand this is a consequence.

I have a feeling that people believe they can get more security out of
the CAA RR than they in fact can.  CAA is quite good, I think, for
positive affirmations about what an operator requires.  It's hopeles
at constraining behaviour on names that do not yet exist and so on,
and I think there are gaps in the way it can apply down the tree that
make such an approach risky.

> If a browser gets it wrong, or 2 browsers are inconsistent

Just so we're clear: both of those are descriptions of the state of
affairs today.  I think browser developers are aware of this, and wish
they had something better, but the DNS does not work the way many
people seem to think it does.  Remember, it's just a namespace tree:
the administrative relationships among the levels are not in the DNS,
and they're not available reliably anywhere else, either.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jul 2012 00:37:56 -0400

> Or the CAA rule could be: a CA must not issue a wildcard cert for *.example.com unless it is allowed to issue a cert for example.com. Then you don't need any extra CAA records. Or define a ";wildca…

This just ploughs right back into the tree-climbing problem, as soon
as you get to *.a.example.com.  And you again have to be sure that
example.com's policies legitimately apply to b.a.example.com, and I
don't see how you can know that.  It could be that b.a.example.com is
controlled by a different legal entity.  (Again, maybe we're willing
to make this trade-off, but if so it needs to be explicit.)

> Wrong? It proves there is no CAA record to prevent cert issuance. It proves there is no name today, but perhaps you are waiting until you have the cert before launching. Perhaps some CAs require a…

If a CA is issuing a cert for a name that is provably non-existent,
what are they certifying?  I don't understand this use case.  This
undoubtedly displays my gross ignorance.  But isn't the cert supposed
to be over a name, making a binding to an organization?  If the name
is provably non-existent at the time the CA issues such a cert, what
is it binding to?  (Feel free at this point to tell me I should shut
up until I have read $tome.  I appear to have a poor grasp of
something here.  A pointer to the correct $tome would be helpful.)

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 20 Jul 2012 15:10:03 +1000

> > Or the CAA rule could be: a CA must not issue a wildcard cert for
> *.example.com unless it is allowed to issue a cert for example.com.
> Then you don't need any extra CAA records. Or define a
> ";wildcard=yes|no" parameter for the CAA record.
> >
> 
> > Wrong? It proves there is no CAA record to prevent cert issuance. It
> proves there is no name today, but perhaps you are waiting until you
> have the cert before launching. Perhaps some CAs require a DNS entry to
> exist as part of validating a cert request, but that is a separate
> issue from CAA.
> >
> 

The CA/Browser Forum Baseline Requirements, section 11.1 "Verification Practices: Authorization by Domain Name Registrant" [http://www.cabforum.org/Baseline_Requirements_V1.pdf §11.1].

It gives various ways to confirm domain "ownership", most of which don't require a DNS lookup of the domain.

"Public Suffixes" are heuristic, inconsistent, riddled with corner cases etc.
But in the vast majority of cases they will be consistent across browsers and CAs.
And site owners can test how their domain is handled in all the common browsers if they have any doubts.
If we can only eliminate a variety of certificate mis-issuance from 99% of domains that will still be progress.

--
James Manger

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 10:04:02 -0400

Split DNS is a real-world fact that any proposal has to work with.

MOST corporate sites are only visible to the corporate network. This
is not only acceptable practice it is best security practice.

We could go back to my original proposal:

1) look at the leaf node and use the CAA record there if it exists.
2) If no node is found there, look at the public delegation point that
the CA will use for validation.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Jul 2012 10:11:52 -0400

I'm assuming that your concern with split DNS is that if foo.example.com might is only visible internally, then the CA won't be able to see a CAA record for it?

Can't example.com just provision a CAA record for foo.example.com on the outside?  You can still have the rest of foo.example.com be internal.

Honestly, at this point it really seems like we're over-thinking things here in order to come up with excuses not to do the simple thing.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 10:34:56 -0400

No, if the site in question is topsecret.bbn.com you are not going to
find the military happy that you have revealed the existence of the
service.

I think you are coming up with excuses not to do the thing that has
been thought through be people who are actually in this business and
understand the complexity.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jul 2012 10:43:14 -0400

> find the military happy that you have revealed the existence of the

Those people are dreaming in Technicolor.  Split-brain DNS names leak,
and there is no way to prevent that.  In this particular case, they
leak because, in order to get the CA to issue the cert, you're going
to give them the name.  You've already revealed it to someone. 

I don't understand what value CAA offers in such cases anyway.
Someone who is actually concerned about not leaking such a name would
presumably get themselves set up in such a way that they had a
certificate with which they could issue another certificate for
topsecret.example.com.  If they're in that situation, nobody needs to
do the CAA lookup on that name except themselves, and they can
presumably contact the relevant server.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Jul 2012 10:47:38 -0400

Phil, I told you not to mention topsecret.bbn.com!  Shhhh!

It seems like a questionable practice for a CA to be issuing certs for things he can't get any real information about.

The problem with your original proposal is that there's not a good way for a CA to detect whether there's no zone there or whether there's just no CAA.  So by allowing parents to be used for non-public domains, you're allowing parents to be used for a domain that simply doesn't use CAA, which was the problem with tree climbing in the first place.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 10:50:14 -0400

It isn't a problem at all.

Your view is based on the belief that DNS hierarchy has administrative
significance and in the real world that is almost never the case.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Jul 2012 11:23:31 -0400

> significance and in the real world that is almost never the case.

I fully agree with the claim that the DNS hierarchy has no
administrative significance, and that one can't read the
administrative facts off the tree.

But that's actually a premise _against_ using a parent name's CAA
record to apply to child names.  The very problem of reading
administrative boundaries off the DNS is how we got crude hacks like
publicsuffix.org.

If you really think that the DNS hierarchy has no administrative
significance, then there is exactly one way to handle this, and that's
to test for CAAs _at that name_, and nowhere else.  Apparently,
however, there are some names that do have administrative significance
(the public delegation points).  If you want to inherit data down the
tree from such points, I get the argument; but I think such a decision
needs an explicit defence in the draft, because it creates new issues
on its own.  From my POV, once you start climbing the tree I'd just as
soon you do it in one step, to wherever you think public delegation
points are -- as long as you admit that such a move introduces
possible problems on its own.

Best,

A

-- 
Andrew Sullivan
[email-masked]