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

[Daymion T. Reynolds]

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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180110/fbc63eaf/attachment-0003.html>