[cabfpub] Ballot 218: Remove validation methods #1 and #5

[Ryan Sleevi]

Given that it would be a new method, and not within the realm of presently
permitted, it seems better to separate it out from the removal of existing
methods - would you agree?

On Wed, Jan 10, 2018 at 8:02 PM, Peter Bowen <pzb at amzn.com> wrote:

> Can we also include a validation method based on the one I suggested a
> couple of months ago in https://cabforum.org/
> pipermail/public/2017-October/012423.html ?  That method would provide a
> strong link between Registry/Registrar and CA even when they are not
> affiliates.
>
> Thanks,
> Peter
>
> On Jan 10, 2018, at 4:32 PM, Daymion T. Reynolds via Public <
> public at cabforum.org> wrote:
>
> I am in agreement with this approach.  Thanks Ryan for wrapping this up.
> Daymion
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com <sleevi at google.com>]
> *Sent:* Wednesday, January 10, 2018 4:49 PM
> *To:* Daymion T. Reynolds <dreynolds at godaddy.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>; Kirk
> Hall <Kirk.Hall at entrustdatacard.com>; Tim Hollebeek <
> tim.hollebeek at digicert.com>
> *Subject:* Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5
>
> So to make sure I've captured the discussion points of 3.2.2.4.1 for the
> "things that would be disruptive"
>
> For situations like GoDaddy (in which the CA is the Registrar as well) -
> or for situations like, say, Google Trust Services/Google, in which the CA
> is an Affiliate of the Registrar (I think; I'm sure folks like Amazon with
> its Amazon Trust Services is in a similar space, and no doubt others) - the
> 'goal' is that if the CA believes the Applicant is the same entity as the
> Domain Owner, then it can use that as an effective authorization by virtue
> of the fact that it's the same account that would approve that operation.
>
> For situations like the ccTLDs, particularly those that lack WHOIS, or for
> situations like .gov, it's seen as acceptable that contacting the registry
> to determine who the Domain Name Registrant is, and then using
> 3.2.2.4.2/3.2.2.4.3 methods of validation/contact is seen as viable.
>
> Finally, we have the issue that most folks (all?) seem to agree that
> 3.2.2.4.1 Option 1/Option 2 are not reliably secure, and neither is
> 3.2.2.5. Unfortunately, because of the 'grandfathering' validation clause,
> this makes it difficult to unambiguously ensure (re)validation of domains
> if they use an insecure method.
>
> Daymion, do you think a ballot that:
> - Deprecated 3.2.2.4.1 as previously proposed (e.g. "adding not after
> March")
> - Deprecated 3.2.2.4.5 as previously proposed (e.g. "adding not after
> March")
> - Make the change to Contact as previously discussed, namely: "Domain
> Contact: The Domain Name Registrant, technical contact, or administrative
> contract (or the equivalent under a ccTLD) as listed in the WHOIS record of
> the Base Domain Name or in a DNS SOA record, or as obtained through direct
> contact with the Domain Name Registrar."
> - Introduce 3.2.2.4.11 (a new method), which reads (to be smithed a little
> if necessary):
>
> "3.2.2.4.11 Validating Applicant as a Domain Contact
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Contact. This method may only be used if the CA is
> also the Domain Name Registrar, or an Affiliate of the Registrar, of the
> Base Domain Name.
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names."
>
>
> Yes, this doesn't describe how the CA/Registrar (or
> CA-Affiliate/Registrar) precisely performs this validation, but I'm
> hesitant to add wording such as 'accounts' or 'usernames' or equivalent
> access control levels at this time, and can live with being permissive here
> and then iterating to be tighter around this language. My goal here would
> be to make it clear that Option #1 and Option #2 of 3.2.2.4.1 are
> unacceptable, but unfortunately the poor wording of 3.2.2.4 and 4.2.1 means
> we have to effectively remove/forbid 3.2.2.4.1 entirely and then re-add the
> bits that make sense.
>
> On Wed, Jan 10, 2018 at 6:16 PM, Daymion T. Reynolds <
> dreynolds at godaddy.com> wrote:
>
> Ryan,
>
> Q: Can you explain why you do not believe it is more secure?
> A: I am not stating its more secure, but .1 Option #3 is on par with other
> deemed secure options. It is secure because only the domain owner is the
> authorized user to a registrars account, and only they can order a cert for
> a specific domain. If more transparency is a concern, let’s discuss what
> would be acceptable.
>
> Q: I don't believe this is universally the case. Consider the situation of
> registrars and registries that allow signing in without a 2FA, but require
> changes to use a 2FA. I realize a response might be "Well, the registrar
> could just require 2FA for issuing a cert" - and while that would be in
> theory possible, there's absolutely zero assurance for relying parties and
> browsers as to the registrars (and CAs) practices. I hope you can see why
> this remains a fundamentally problematic proposal.
> A: I agree, everyone should be using 2FA. Unpacking this a bit further, as
> your statement is close to the crux of my argument. If the registrar
> account is compromised, everything about the domain is in question. If
> registrar account compromise is a concern for .1 option #3 then it also a
> question for .4 Domain Contact, .7 DNS Change and .8 IP Address validation.
> All of these require the registrar account to be secure. I believe .4, .7,
> and .8 are secure practices.
>
> Q: I think it's important to be precise here when talking about .1. Is it
> correct to say you are only concerned with retaining some notion of .1
> Option 3? When we say "don't eliminate .1", I think that carries with it
> the significant (and insecure) suggestion of retaining .1 Option 1 and .1
> Option 2.
> A: Agreed, and sorry for not being precise. You are correct I am only
> concerned with Option #3, as I believe it is a secure practice on par with
> .7 and .8. I agree with your position on option #1 & #2.
>
> Thanks for your time discussing this,
> Daymion
>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Wednesday, January 10, 2018 1:50 PM
> *To:* Daymion T. Reynolds <dreynolds at godaddy.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>; Kirk
> Hall <Kirk.Hall at entrustdatacard.com>; Tim Hollebeek <
> tim.hollebeek at digicert.com>
> *Subject:* Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5
>
>
>
> On Wed, Jan 10, 2018 at 2:37 PM, Daymion T. Reynolds <
> dreynolds at godaddy.com> wrote:
>
> Ryan,
>               Thank you for replying as this is a good discussion to have.
> “Direct contact” is great method when you don’t have a clean, reliable data
> source to validate ownership. For Registrar / CA combos, whereby the same
> account ordered the domain and the cert, knowledge of ownership is robust.
> Requiring a second contact doesn’t seem more secure, but rather seems more
> cumbersome for an already complex process.
>
>
> Can you explain why you do not believe it is more secure?
>
>
> If you are concerned about the possibility of a customer account being
> compromised, it doesn’t change the risk. If there was a compromise they
> would have control over DNS and could then domain validate a cert order
> from anyone.
>
>
> I don't believe this is universally the case. Consider the situation of
> registrars and registries that allow signing in without a 2FA, but require
> changes to use a 2FA. I realize a response might be "Well, the registrar
> could just require 2FA for issuing a cert" - and while that would be in
> theory possible, there's absolutely zero assurance for relying parties and
> browsers as to the registrars (and CAs) practices. I hope you can see why
> this remains a fundamentally problematic proposal.
>
>
>               Rather than eliminate .1, I believe a better course of
> action would be to add transparency and lock down when you can and cannot
> use the registrar validation method.
>
>
> I think it's important to be precise here when talking about .1. Is it
> correct to say you are only concerned with retaining some notion of .1
> Option 3? When we say "don't eliminate .1", I think that carries with it
> the significant (and insecure) suggestion of retaining .1 Option 1 and .1
> Option 2.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180111/d7770c0e/attachment-0003.html>