[cabf_validation] Replacement for Domain Validation Method 6

[Ryan Sleevi]

On Mon, Nov 4, 2019 at 12:54 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan,
>
>
>
> Thanks for the comments and especially for the proposed re-wording that
> would be acceptable, that saves a lot of time.  I agree with all of your
> comments and will incorporate them except for the comment about the
> location of the file.
>

Great. Glad the context and the changes were acceptable.


>
>
> The intent of this change was to remove “or another path registered with
> IANA for the purpose of Domain Validation” and to specifically define the 2
> places where the validation could be done.  Is it an important security
> related recommendation to specify ACME MUST use only
> '.well-known/acme-challenge/ and that all other  implementing of this
> method MUST use /.well-known/pki-validation (if that is what you were
> recommending)?  Since multiple random Numbers may be in the same file, I
> don’t think this will cause interoperability issues, but I wasn’t sure what
> motived your recommendation.
>

Yes, I'm suggesting it's both a security and an interoperability issue. We
want the contents of .well-known/acme-challenge, which is registered with
IANA at
https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml for
use with RFC 8555, Section 8.3, to be used in accordance with RFC 8555,
which defines an overall protocol for validating.

In general, this is a category of attacks known as "cross-protocol attacks"
- in which the requests/responses from one protocol are confused as
another. This is particularly pervasive in plaintext protocols, like
3.2.2.4.6 is trying to be. Classic examples are confusing HTTP requests for
IRC or SMTP traffic in web browsers (this is known as "XPS" or
cross-protocol scripting). This is also why we tightened down the
TXT records for the new validation methods, since they're plaintext, to
avoid any confusion.

That's why the easiest resolution was to explicitly list http-01 as a
distinct validation method, with its RFC-specified processing model, and
then if we want to continue with something that isn't http-01, that's a
separate method. I think we're better off wholesale moving to HTTP-01,
which has received much wider review and security analysis, but I can
understand that some CAs are not yet ready to transition, and I wouldn't
want to block tightening up 3.2.2.4.6 on that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191104/d0e3d434/attachment.html>