[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Wed, Mar 21, 2018 at 5:41 AM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I’m suggesting we might want to consider forbidding or restricting it if
> after analyzing it we decide there are things about it we don’t like, in
> the same way we are considering potentially tightening up other things
> about domain validation methods.
>

I don't think that's a realistic position. I'm suggesting that we cannot
meaningfully forbid or restrict, therefore, such exercises are not fruitful.


> I don’t have strong feelings about it right now, but it is certainly not
> something we contemplated when we originally thought about the
> requirements.  And that makes me a bit uneasy, especially since we spent a
> lot of time in many cases while writing the requirements to make sure that
> domain validations were fresh and that the operator was affirmatively
> involved.
>

I think it's worth analyzing what it means to be affirmatively involved. If
we want there to be an explicit configuration of a random value each time,
then we'd have to prevent CNAME-or-zone-cuts entirely for DNS (which will
be more complex than specifying CAA), and we'd have to determine some way
of constructing a meaningfully secure-yet-dynamic email system (since, as I
mentioned, they can always just forward the e-mail). Most likely, it would
have to involve some manual, out-of-band communication of the random value,
and the email containing the link - but it's still turtles all the way down.


> These sorts of things turn that on their head.  That may be fine, but we
> should look at them with a critical eye and see if they do what we want.
> The answer may be yes.  I’m still thinking them through.
>

Right, and I'm disagreeing with that framing for how to approach it. If
we're going to Have Opinions about it, we first have to explore whether
it's even possible to meaningfully do anything about it. If not, it's a lot
of handwringing and pearl-clasping for nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180321/f580b00e/attachment.html>