[cabf_validation] Minutes from the meeting of 2 August 2018

[Ryan Sleevi]

On Thu, Aug 9, 2018 at 5:28 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> Thanks for circulating these, Wayne.
>>
>> Tim, I'm hoping you can expand more on "I’m particularly disturbed when a
>> redirect points back to a site run by the CA.". Are there existing threads
>> where you flesh out and articulate these concerns that you could link to?
>> If not, could you expand on why you're particularly disturbed?
>>
>> FWIW and without taking a position, I believe the concern here is that
> allowing a redirect to the CA creates a "perma-delegation" of authority to
> the CA that, when used much later, may not reflect the intent of the site
> owner, just as the ability to indefinitely reuse a random value placed on
> the website would if that were permitted. Of course this can also be
> achieved with automation like Certbot, but most of our validation methods
> are designed to require the domain/site owner to consciously approve the
> request. My recollection is that the passive nature of method #1 was one
> argument against it.
>

Thanks. I definitely don't think those arguments hold water, especially
with CAs' seemingly preferred methods of validation. For example, consider
Tim's proposal to allow delegation to an e-mail address - there's nothing
preventing that delegation to go to the CA. Or Bruce's discussion around
providing information about phone numbers - any process there is going to
inherently be dealing with someone on the 'other end' who could just as
well be a representative of a CA.

The same logic applies to allowing the use of DNS validation itself - while
we allow the target of a CNAME itself to be a valid form of delegation, by
doing anything with DNS to begin with, we accept the possibility that the
given record (e.g. A in the case of connecting to the host, TXT or CAA
otherwise) could itself be a delegated target as the result of following
CNAMEs. Indeed, the CAA spec allows this.

Or consider the discussion of CA authorization based on account holder,
which is similarly a persistent delegation. If we're willing to look at it
closely, we can also see that any CA's reuse of information is,
fundamentally, the same notion of delegating authority to a CA.

This even applies to methods like postcard based validation - where the
mail team could simply route and forward all mail to a CA or a third-party.

There's an inherent flaw to the thinking which says, at the same time, "We
should allow third-parties the ability to approve certificates" (in this
case, the active discussions where the "DNS team" != the "certificate team"
- hence discussions like .13 / .14), while also saying "We should prohibit
some third-parties" - that doesn't work, not without adding more validation
requirements to the third-party process and making it more difficult.
Consider what would happen if, in order to prevent the CA being delegated
by the phone number method, we required that the phone number method could
only be used for EV certificates, and MUST speak to a named officer of the
company, and must record a voice print for future comparison. That's the
sort of thinking we'd end up needing to go to, if the goal is to prevent
the CA.

That's why I'm a big surprised by the reaction against redirects,
especially against cross-domain redirects. The security properties still
require the redirected-to target to provide the Random Value, which is not
going to be derived from the HTTP request, so we know there's some unique
out-of-band knowledge that the target must have. I absolutely agree that in
the old system of CAs checking to see if a request query string was echo'd
back, redirects would be a security disaster (consider open redirects), the
slight improvements made to use the .well-known and structure the form of
the request/response pair seem to mitigate such risks.

So I'm hoping for a better articulation of those risks, especially in light
of our other validation methods. If the goal is, for example, to require a
strong binding to key, then we'd also need to consider situations where if
using phone validation, in order to achieve that property, the Applicant
should read out the applied for public key, to ensure there is strong
binding between the key and domain. If we recognize that as silly, then we
have to recognize the discomfort for redirects going to the CA, at least as
presented so far, is just as silly.


> Is there a draft version circulating with these proposed changes? I may
>> have missed it, but I couldn't find it while scanning my e-mail.
>>
>>
> I believe the proposal is under method 3 in the Validation Summit Findings
> doc.
>

I see. It would be great to split these out into concrete text proposals,
as the document is getting rather unwieldy, which would allow more
efficient commenting and reviewing of these proposals prior to them being
put forward into a week-long discussion phase.


> 5. Validation Methods in Certificates
>>> Wayne: my mental model is that certificates are issued as soon as each
>>> SAN passes one method of domain validation, but Doug pointed out on the
>>> list that some CAs might validate with multiple methods. The CA can just
>>> choose which method to indicate in the certificate, or can indicate
>>> multiple methods. The concern is if one method is found to be insecure,
>>> then that doesn’t necessarily mean that the cert needs to be replaced. In
>>> fact, CAs often revalidate rather than reissuing certs when a validation
>>> vulnerability is found. This leads to the conclusion that the validation
>>> method information in a certificate can’t be used to determine that the
>>> certificate needs to be revoked.
>>> Tim: I agree. The BRs state that the CA must validate using “at least
>>> one of the methods below”.
>>>
>>
>> Can someone describe a bit more about the scenarios in which a CA
>> performs validation using several simultaneous methods?
>>
>>
> The scenario I'm thinking about is a CA that simultaneously attempts
> multiple automated methods of domain validation where more than one can
> succeed prior to issuance. Regardless of the scenario, this is possible so
> we should account for it.
>

I'd like to better understand how realistic it is. There are things that
are possible in the real world that we don't represent in certificates, and
it's not been too bad. Consider, for example, where a given Subscriber has
multiple authorized Affiliates, all sharing the same technical
infrastructure. For an EV certificate, we don't try to represent every
Affiliates information within the certificate as well - that is, saying
Google and Alphabet both might be using the certificate (as an example) -
but instead issue two certificates, one for Google and one for Alphabet.
Similarly, if a given organization has a single incorporated address, but
multiple mailing addresses, we don't try to represent all of those distinct
addresses within the Subject DN or SAN.

That's why I'd like to better understand how this works in the real world,
and how common it is. With the current syntax, one could express a
certificate for each level of assurance / validation provided, which allows
both RPs and Subscribers to choose how best to present that information
(e.g. presenting the strongest method of validation, for example). I'm not
aware of any CAs, members or non-, that require multiple forms of domain
validation prior to issuance. If anyone is aware of a CP/CPS that states
that 100% of certificates require such multiple validations, I'd be really
keen to read more. In the absence of such a policy, we're saying that a CAs
issuance of a certificate is ultimately triggered by "at least 1" form of
validation (and additional validations don't matter because they aren't
necessary towards the issuance), and so choosing which form of validation
to express in a single certificate seems a reasonable path.


>
> Doug: I also agree, but we don’t know what browsers will do with this
>>> information, so we have to assume that browsers will use it to make trust
>>> decisions.
>>> Wayne: I view this as information, not a way to enforce policies, and
>>> this discussion makes the case for that.
>>> Doug: Can the intent be part of the ballot?
>>> Wayne: Requirements can’t really describe intent, but I’d be happy to
>>> add that to the introductory language of the ballot.
>>> Tim: Another question is the ability to describe which sub-methods were
>>> used
>>> Wayne: the ballot expresses the current scheme of describing methods, so
>>> that scheme would need to change first. In the current scheme, we should
>>> break a method with N sub methods into N new methods.
>>> Tim: I agree. Another concern is with CAA, where constantly changing
>>> method numbers could cause problems when certificates are renewed
>>> Bruce: I don’t see method numbers constantly changing once we get
>>> through our review of all the methods. Agree that method 2 should be 3
>>> methods.
>>> Doug: Method 2 could really be 9 methods. Or we could have one method
>>> for all flavors of phone validation, for instance. We need to decide if we
>>> want to make methods more granular. Not convinced it’s worth turning one
>>> method into 9.
>>> Corey: If we don’t make things more granular, there isn’t enough value
>>> in encoding the method into the cert. The OID for the old and new method 10
>>> would be the same.
>>> Tim: Method 10 is a problem child. It needs to be fixed.
>>>
>>
>> Aren't any issues with this resolved by indicating the earliest of the
>> validation that occurred?
>>
>
> I'm not following - please explain your thinking.
>

Sure. I think we have to work back to understand the goals. Certainly, a
goal is to enable relying parties - not just browsers - to make effective
trust decisions. This is the same argument that CAs make for adding OV/EV
information, despite the fact that the rely on a human validating rather
than a machine. If we accept that is at least one premise, then the
argument for including the potential sub-methods of validating is because
not all sub-methods provide the same level of assurance, and we believe
that expressing those differing levels of assurance is worthwhile.

One approach to acknowledging that a given method - say, phone - provides
differing levels of assurance is, as noted, to break the given method into
each method that provides a distinct and different level of assurance. We
might have "phone to named officer" and "phone based on DNS" or some other
arbitrary and made-up scheme where we think differing levels of assurance
are provided.

Another approach is to acknowledge that we don't really care about the
incremental improvement to the levels of assurance between a given
validation method, but what we do care is whether or not a given sub-method
provides adequate assurance, for some value of adequate. In this approach,
if a given sub-method no longer provides adequate levels of assurance, we'd
expect to see it removed from the BRs as an option. Even if we kept the
same numbering for the overall method (e.g. ".6"), whether or not the level
of assurance was adequate can be determined based on whether it was "old
.6" or "new .6", which can be evaluated based on when the validation itself
was performed. Alternatively, of course, if we removed .6 sub-method 3
(using made up numbers here), we might also decide that .6 is deprecated,
and the new hotness is .16 (which is .6 with sub-methods 1 and 2). That
equally helps determine where the 'floor' was for the level of assurance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180810/a7dc0037/attachment-0001.html>