Re: [pkix] [Gen-art] Gen-ART review of draft-ietf-pkix-caa-10

["Richard L. Barnes" <[e-mail]>]

On Jul 11, 2012, at 10:22 AM, Phillip Hallam-Baker wrote:

> On Tue, Jul 10, 2012 at 2:30 PM, Richard L. Barnes <[e-mail]> wrote:
>> Areas of agreement trimmed; responses inline.
>> 
>>>>> General: Tree walking
>>>>> The tree walking algorithm specified in Section 3 seems like a really bad idea.  It saves the domain holder from having to deploy separate CAA records for every subdomain, but has some tricky consequences.  For example, because the algorithm stops at the first CAA it finds, authorizations don't flow all the way down the tree, just to the first CAA point, where they get replaced.  Likewise, if a domain holder doesn't agree with a parent domain's CAAs for his domain, he's forced to deploy a null CAA defensively.  Recommend removing the tree walking / Extended Issuer Authorization Set.
>>> 
>>> We went through this on the list. Originally there was no tree
>>> walking, only the leaf node and public delegation point were looked
>>> at. This was changed to being the whole length of the tree because it
>>> is only being done at time of issue of a cert. I think this makes best
>>> sense.
>> 
>> Was the possibility of looking only at the leaf node discussed?  It seems like if you're requesting a cert for a domain, you should be authorized to provision a record for that domain, so walking up the tree is really just an optimization.
> 
> 
> Today the practice for validation checks is to ONLY check for the
> public delegation point. Subdomains are not a concern for CAs, they
> are assumed to be purely a matter of internal administrative policy.
> 
> The number of domains where this is not the case is vanishingly small.
> Yes, at MIT there are subdomains for the departments but outside CSAIL
> they are all run by the MIT network staff anyway.
> 
> Checking the leaf node only would make no sense at all to me, consider
> the cases for leaf.example.com and example.com
> 
> 1) No CAA record at either - anyone can issue
> 
> 2) CAA record at example.com for Alice.ca,
>     only Alice can issue for *.example.com
> 
> 3) CAA record at leaf.example.com for Bob.ca,
>     only Bob can issue for leaf.example,com, anyone can issue for the rest
> 
> 4) CAA record at leaf.example.com for Bob.ca, CAA record at
> example.com for Alice.ca,
>     only Bob can issue for leaf.example,com, anyone can issue for the rest
> 
> 
> You seem to be arguing that in case 2, anyone could issue for
> leaf.example.com. That seems like nonsense to me.

No, I'm saying that the policy should be default-deny with authorizations applying to specific names (not sub-domains).  

1) No CAA record: 
   Nobody is authorized to issue

2) CAA at example.com for Alice: 
   Only Alice can issue for example.com (exactly)
   Nobody is authorized to issue for any other name

3) CAA at leaf.example.com for Bob: 
   Only Bob can issue for leaf.example.com (exactly)
   Nobody is authorized to issue for any other name

4) CAA at leaf.example.com/Bob, example.com/Alice:
   Only Bob can issue for leaf.example.com
   Only Alice can issue for example.com
   Nobody is authorized to issue for any other name

It seems like what you want is an explicit assertion that flows down (as opposed to a global default deny).  That's a different semantic than the positive authorization that the "issue" tag creates.  Why not just create another  


>>> The assumption is that a DNS domain superior node has the capability
>>> to enforce as much control as it likes on subordinate nodes. Therefore
>>> any delegation of control is a matter of choice and should be assumed
>>> is done because the superior node wants to delegate that control.
>>> 
>>> Since CAA authorizations are additive, this is the only way that
>>> allows the use cases to be met. There is a need to carve out
>>> exceptions when a subdomain is being delegated to another party such
>>> as an outsourced mail provider.
>> 
>>> Without any form of climbing, the spec is broken as an attacker can
>>> request a certificate for bogus.paypal.com and evade the CAA checks
>>> completely.
>> 
>> OK, I think I understand this better now.  As I understand the scenario, you mean:
>> 1. paypal.com provisions CAA 0 issue ";"
>> 2. Attacker who cannot control bogus.paypal.com asks for a cert
>> 3. CA finds nothing under bogus.paypal.com, but finds ";" CAA under paypal.com
>> 4. Because (1) there is a CAA record, and (2) issuing would not match a CAA record, the CA MUST NOT issue.
>> 
>> The crux of this seems to be that provisioning a null issuer (";") conveys a different policy than having no CAA record at all.  That was not apparent to me from reading the text, so it might be something helpful to call out specifically.
>> 
>> Alternatively, couldn't you just say that in situations where a CA requires CAA, it MUST NOT issue if there are no CAA records provisioned for the target domain?  It seems like that would be simpler (as a true default-deny), and would address your use case without the need for tree-walking.
> 
> Are you seriously suggesting that CAs are going to deploy a spec that
> required every one of their customers to deploy a new record before
> they could issue a cert?

No, I'm saying that "in situations where the CA requires CAA", the customer would be required to provision a record.  Which situations require CAA would be up to a CA's Certificate Policy.

All this document defines is a standard version of Google's "set a TXT record with a validation token" verification protocol for Google Apps.  That protocol (1) only looks at the leaf, (2) doesn't require a DNS record in all cases, and (3) works.
<http://support.google.com/a/bin/topic.py?hl=en&topic=9196>



>>>>> General: Public Delegation Points
>>>>> The concept of a Public Delegation Point seems unhelpful here, because it is not well-defined.
>>> 
>>> CAs are already required to manage lists of public delegation points
>>> to ensure that certificates are properly issued. It is a fuzzy concept
>>> because of the way DNS has evolved and in particular the way certain
>>> TLDs like .uk are structured.
>> 
>> OK.  I did not realize this.  I certainly agree it's fuzzy!
>> 
>> Is there any guidance you could point to on how a CA should determine what domains are public delegation points?  What happens if it guesses wrong?  If a CA doesn't know anything about public delegation points, is it safe to just go all the way to the root?
> 
> That is all stuff that represents 'policy' which would have to be
> harmonized in CABForum if it is going to be harmonized anywhere.
> 
> One of the new corner cases is that we now have a real possibility of
> TLDs that are going to not be public delegation points like .google
> and .apple.

This seems like all the more reason to avoid tree walking.


>>>>> Section 5.4. "... civil or criminal sanctions."
>>>>> This is complete speculation, and highly contingent on legal matters that don't belong in a technical specification.  Suggested cutting this sentence off:
>>>>> "It is thus unlikely that the attack would succeed."
>>> 
>>> No, knowingly making an untrue statement to obtain a valuable
>>> consideration is fraud under UK, US and pretty much any other legal
>>> system. An audit statement is quite obviously a valuable
>>> consideration.
>>> 
>>> I don't see that there is any speculation there. I will ask the
>>> CABForum folk for an opinion. We have no shortage of lawyers.
>> 
>> I'm not trying to bring lawyers to bear on this document, I'm trying to keep them out :)
>> 
>> The text in question simply isn't technically relevant or useful, and could be wrong in some places.
>> 
>> (What does this have to do with audit?)
> 
> Once we get CAA signed off here, the next stage is to have it adopted
> as a Basic Requirement for validation by CABForum. At which point
> compliance with CAA will become an audit requirement within a couple
> of years.
> 
> This is an accountability control and so the enforcement is by
> consequences and not purely technical.

If we're seriously going to do legal stuff here, then we need to actually have some lawyers review the document.  Has that been done?  Otherwise, let's take the legal language out.

We do not have to broach legal topics in this document in order for it to be a useful accountability control.  If we define a clear technical mechanism, then the CABF or some other group can define how that technical mechanism should be used and wrap legal requirements around it.  



>>>>> MINOR:
>>>>> 
>>>>> Section 2. "CAA records MAY be used by Certificate Evaluators..."
>>>>> This recommendation seems to contradict the sentence immediately preceding.  From the perspective of deciding whether a certificate is valid, a Certificate Evaluator is the same as a Relying Party, so if RPs shouldn't use CAA, then neither should Certificate Evaluators.  (In general, the concept of a Certificate Evaluator seems unhelpful and confusing; I would suggest just using RP, if anything.)
>>> 
>>> The circumstances are entirely different.
>>> 
>>> It is assumed that a client only has direct access to the DNS which
>>> only holds current statements about the DNS and can only make a go/no
>>> go decision. I don't think that you are going to find any DNS
>>> information suitable for a go/no go decision.
>>> 
>>> A certificate evaluator is going to be taking information from a wide
>>> variety of sources and make use of archival series. If it has been
>>> sampling the CAA records of a domain on a daily basis for 5 years it
>>> can make decisions that are rather more robust. But even then I would
>>> not want to rely on the DNS information alone, I would tie in
>>> information from checking the Web site, IP blacklists and the like.
>>> 
>>> CAA records are intelligence, but they are not directly actionable
>>> without other data.
>> 
>> Could you provide an example of a Certificate Evaluator in the real world?
> 
> Comodo CertSentry, Kasperky also have a product. I would expect McAfee
> and Symantec also have ideas for product.
> 
> Before that we had the EFF certificate observatory, Convergence and
> Perspectives. Though I suspect those will be seen as forerunners of
> the commercial services as open source services don't scale quite the
> same way as open source software as the marginal cost of service is
> negligible rather than zero and those negligible amounts add up.
> 
> I have a draft out on an open protocol, reference code to follow:
> 
> http://www.ietf.org/id/draft-hallambaker-omnibroker-00.txt

OK.  Leave it in if you want.  I still don't really find it all that helpful; these entities exist already (based on certs and CRLs) without a need for standards guidance.


>>>>> Section 2.1. "express written authority"
>>>>> Requiring "written" authority seems like it goes beyond the scope of a technical specification.
>>> 
>>> Written authority means authority expressed in a fixed medium that can
>>> be produced on demand. That seems like a necessary requirement if the
>>> accountability control is going to mean anything. Written does not
>>> have to be written on paper, emails are written but they do have to be
>>> fixed.
>>> 
>>> I don't think we want to allow someone to claim that they were
>>> authorized to issue for Comodo or Symantec on the basis of a phone
>>> call or a chat session.
>> 
>> That seems like it's up to the CA!  I don't see much reason why an XMPP message should have less authority than an email -- they're both just bits.
> 
> The point is that you have to save it.
> 
> If you have a saved jabber log, well it might count. But since jabber
> is a conversation, well I don't think I would rely on it for authority
> to issue on behalf of Symantec.
> 
>> This is a policy/legal-level requirement, not a technical one.
> 
> As is pretty much the whole subject matter of PKI.

Like I said above, if this document is going to specify legal requirements, then bring in the lawyers.  (Cf. RFC 3647)  Otherwise, just leave it out, and leave the lawyering to the attorneys at the CAs / CABF.  


>>>>> Section 4.2. "This form of issue restriction..."
>>>>> It would be helpful to explain this a little more fully.  The major point of a "null CAA" record seems to (1) stop the tree-climbing in the CA processing, and (2) let CAs know that the domain owner understands CAA.  If the tree-climbing is removed (as suggested above), then is there really value in this beyond having no CAA at all?  (If not, then just make the "[domain]" above into "domain".)
>>> 
>>> We have a very good reason for requiring climbing.
>> 
>> As noted above, it would be helpful to explain that the reason is (2), i.e., that the policy is different if there is a CAA vs. if there isn't, even if the CAA is empty.  So showing that you understand CAA activates the default-deny policy.
>> 
>> Also as above, it would be simpler if this mechanism could be true default-deny.
> 
> And a non-starter for deployment.

See the Google example above.  They require every single one of their Google Apps customers to deploy a domain name or a special web page.  This has not killed their deployment.

This document also doesn't say that every CA in the world has to require CAA for every transaction.  It says "If you're using CAA for authorization, here's where you look and what the octets mean."  CA policy says when you use CAA for authorization.


>>>>> Section 3. Bullets
>>>>> It would be helpful to describe the process for assembling the Extended Issuer Authorization Set.  Namely, something like the following:
>>>>> 1. Check for CAA records under the target domain name.
>>>>> 2. If they exist, then they are the EIAS.
>>>>> 3. Otherwise, remove a label from the name
>>>>> 4. If the name is now empty (the root), then the EIAS is empty
>>>>> 5. Otherwise go to step (1) with the new domain name
>>>>> 
>>>>> Section 5. "Observance of CAA records by issuers is subject to accountability controls."
>>>>> This is obviously not true as written;even after this RFC is published, not every CA will have controls enforced on it.  Suggested text:
>>>>> "An issuer's practices with regard to CAA records can be made subject to accountability  controls."
>>> 
>>> I think it is a MAY.
>>> 
>>> The criteria here will come from CABForum but I don't want to tie this
>>> draft to one particular body as there may be others.
>> 
>> Hence the "can be", as in "Someone can do this if they want to".  Like CABF.
> 
> I think that counts as normative language.

I don't see "CAN BE" in RFC 2119.  How can the expression of an existential possibility be normative?  If I say, "Cookies can be delicious, but they can also be too chewy", how do you write a compliance test for that?