[cabfpub] Pre-Ballot 169 - Revised Validation Requirements

[Ryan Sleevi]

On Tue, Jul 19, 2016 at 4:25 PM, Jacob Hoffman-Andrews <jsha at letsencrypt.org
> wrote:
>
> My reasoning is, like you said, related to the ease of obtaining a
> certificate. Specifically, allowing verification through a given port makes
> it possible to write software that automatically requests certificates for
> itself. People have already written web servers that do that. Ideally it
> would be possible to do the same for POP, IMAP, and the other SMTP ports.
>

I'm not sure I share your goal or agree it's a good one, quite frankly,
primarily because of the potential for combinatorial growth of attack
surface that each port adds (note how Authorized Ports are reused in
several methods of validation). Throw in protocol confusion issues, and the
surface grows.

As discussed in the past, I still have fundamental unease and reservations
about the use of non-DNS methods to obtain certificates. There are a number
of ways to mitigate this in the future (which I say primarily because I
don't believe it should be a reason to hold back this ballot), whether it
be by restricting such certificates to SRVName certificates or mandated CAA
with a means for CAA to disable some methods, but I don't share your
enthusiasm for increasing the ways in which certs can be issued. This is
precisely because it's already rather difficult to restrict the ways today.

For example, even this week, and despite doing everything reasonably
possible to restrict accidental misissuance, we saw a CA issue certificates
for a Google domain in a manner that complies with the Baseline
Requirements, but goes against our specific, expressed, and programatically
enforced wishes. The CA in particular doesn't check CAA, and used a
file-based means of validation - but didn't use
/.well-known/pki-validation/ to do so. The means of validation that this
particular CA uses to produce the filepath is something that we, Google,
simply cannot prevent while delivering our services to our users. That's
not a good state.

Because each method introduced - and each port introduced - adds yet
another attack surface that every vendor has to comprehensively attempt to
defend against, I'm fairly opposed to adding new methods that don't
authoritatively tie to DNS.


> A related idea: What would you think of an IANA-allocated port
> specifically for certificate validation? That would decrease the risk that
> software running on that port was not authorized to request certificate
> issuance, and would make it possible to write a system-level service that
> can request certificates for various components on the system without worry
> about port conflicts.
>

I think it's a fairly broad claim that it will "decrease the risk that
software running on that port was not authorized to request certificate
issuance", and think it's very unlikely to be true. Yet again, everyone
would have to block that port. I would think it would be as objectionable
to proposing adding a new email alias for email validation - it's precisely
the kind of expansion of attack surface that we should be looking to avoid,
if not outright reduce.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160719/ba0afce1/attachment.html