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

[Phillip Hallam-Baker <[e-mail]>]

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.


>> 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?

> Also, the need to carve out exceptions goes away if you only look at the leaf.

So does the effectiveness of the control.


>>>> 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.




>>>> 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.


>>>> 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


>>>> 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.


>>>> Section 4.1.1. "ASCII letter and numbers in lower case."
>>>> Is there any particular reason that this has to be lower case?  It might be helpful to specify ABNF for it, e.g.:
>>>> tag = 1*(ALPHA/DIGIT)
>>
>> There is no particular reason to use upper case. Mandating registry
>> tags be lower case is a low cost way to avoid ambiguity and confusion
>> down the line.
>
> I don't really agree that lower case has any benefit.  Requiring it to be lower case just means that someone has to check this and reject.  If you want case not to cause mismatches, make it case insensitive.  If you want to make matching simple make it case sensitive and allow both cases.
>
> Still think that there needs to be ABNF for this.
>
>
>>>> 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.


>>>> EDITORIAL:
>>>>
>>>> Section 2. "issueance" -> "issuance"
>>>>
>>>> Section 2. "Certificate Policy Statement"
>>>> Seems like "Certification Practices Statement" would be more appropriate here.
>>
>> No, there is a difference between the two and I am very clear on which
>> one is being specified.
>>
>> A policy statement sets out criteria that the practices must meet. A
>> relying party should only rely on the undertakings set out in the
>> policy. The practices statement specifies how the policy is met and is
>> principally a document for the auditors to work against.
>
> What statement are you referring to?  In RFC 3647, I see only a "Certificate Policy" and a "Certification Practice Statement", not "Certificate Policy Statement".
>
> Maybe you mean "Certificate Policy"?  It seems like a mention of CAA would fit under the "Certificate Application Processing" heading:
> <http://tools.ietf.org/html/rfc3647#section-4.4.2>

Ah, the word statement should have been killed.


>>>> 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.

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