In addition to the GDPR concerns over WHOIS and RDAP data, reliance upon
these data sources has a crucial differentiation from other domain
validation methods.
Specifically, the WHOIS/RDAP data sources are entirely "off-path" with
respect to how a browser will locate and access a given site. To my way of
thinking, this renders these mechanisms functionally inferior to an
"on-path" mechanism, such as reliances upon demonstrated change control
over an authoritative DNS record or even demonstration content change
control over a website.
Since domain validation is, in theory, about validating that the party to
whom a certificate is to be issued has demonstrated control over the
subject of the desired name(s) or the name space of the desired name(s), it
seems clear that "off-path" validation is less valuable as a security
measure.
Although I'm aware that the BRs bless a number of methods, it's also clear
that methods have been excluded by the Mozilla root program before. Is it
time to consider further winnowing down the accepted methods?
On Thu, Feb 28, 2019 at 5:43 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Feb 28, 2019 at 6:21 AM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Thu, 28 Feb 2019 05:52:14 +0000
> > Jeremy Rowley via dev-security-policy
> > <dev-security-policy@lists.mozilla.org> wrote:
> >
> > Hi Jeremy,
> >
> > > 4. The validation agent specified the approval scope as id-addr.arpa
> >
> > I assume this is a typo by you not the agent, for in-addr.arpa ?
> >
> > Meanwhile, and without prejudice to the report itself once made:
> >
> > > 2. The system marked the WHOIS as unavailable for automated parsing
> > > (generally, this happens if we are being throttled or the WHOIS info
> > > is behind a CAPTCHA), which allows a validation agent to manually
> > > upload a WHOIS document
> >
> > This is a potentially large hole in issuance checks based on WHOIS.
> >
> > Operationally the approach taken ("We can't get it to work, press on")
> > makes sense, but if we take a step back there's obvious potential for
> > nasty security surprises like this one.
> >
> > There has to be something we can do here, I will spitball something in
> > a next paragraph just to have something to start with, but to me if it
> > turns out we can't improve on basically "sometimes it doesn't work so
> > we just shrug and move on" we need to start thinking about deprecating
> > this approach altogether. Not just for DigiCert, for everybody.
> >
> > - Spitball: What if the CA/B went to the registries, at least the big
> > ones, and said we need this, strictly for this defined purpose, give
> > us either reliable WHOIS, or RDAP, or direct database access or
> > _something_ we can automate to do these checks ? The nature of CA/B
> > may mean that it's not appropriate to negotiate paying for this
> > (pressuring suppliers to all agree to offer members the same rates is
> > just as much a problem as all agreeing what you'll charge customers)
> > but it should be able to co-ordinate making sure members get access,
> > and that it isn't opened up to dubious data resellers that the
> > registries don't want rifling through their database.
> >
>
> Unfortunately, this is not really viable. The CA/Browser Forum maintains
> relationships with ICANN, as do individual members. While this, on its
> face, seems reasonable, there are practical, business, and legal concerns
> that prevent this from being viable. Further, proposals which would require
> membership in the CA/Browser Forum should, on their face, be rejected - a
> CA should not have to join the Forum in order to be a CA.
>
> I do agree, however, that the use of WHOIS data continues to show
> problematic incidents - whether it's with OCR issues or manual entry - and
> suspect a more meaningful solution is to move away from this model
> entirely. The recently approved methods to the BRs for expressing contact
> information via the DNS directly is one such approach. The GDPR issues
> surrounding WHOIS and RDAP have already led it to be compelling in its own
> right.
>
> Most importantly, you are on the right path of questions, though - which is
> we should examine such incidents systemically and look for improvements,
> and not convince ourselves that the status quo is the best possible
> solution :)
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
