On 01/03/2019 01:04, Matthew Hardeman wrote:
> 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.
>
And there, you completely misunderstood the purpose. The purpose of
domain validation is to determine if the certificate application is
(directly or indirectly) authorized by the domain registrant.
Technical control (via the various automated methods) is a proxy to
this information, but not as close to the truth as WHOIS validations
(provided either is done securely).
The panic mishandling of GDPR concerns by ICANN (something that
continues in the current process to make a "permanent" solution) has
essentially crippled all useful purposes of the WHOIS/RDAP database.
Including making it near impossible to do domain ownership (as opposed
to mere control) validation impossible except for a few national
TLDs that continue to provide open WHOIS.
I sincerely hope that ICANN cleans up its misunderstandings and
reopens WHOIS, at least for domain owners that request this (it
currently can't be done because registrars are vary of implementing
the temporary specification of how to do that, as a new spec is in
the works).
Therefore WHOIS validation should remain valid, but only if the
actual registry/registrar provides authoritative computer readable
data for the domain in question. (Thus having to do OCR or similar
of a picture of text is not acceptable, and neither are manually
entered entries).
In particular "substitute WHOIS" lookups via manual steps that
don't result in the validation computers directly reading the data
from the registrar/registry server should not be allowed.
There are many ways this can be done technically, ranging from a
straightforward WHOIS lookup from multiple network vantage points
to a process where a special web browser is used to authenticate
through CAPTCHAs etc. until the validation system automatically
captures and parses the "known correct" textual web response
from a known registrar/registry url.
This in turn means that IV, OV and EV certs will often need to use
other means of associating the domain control with the certificate
applicant entity. For example one or more challenge values/pins
can be securely provided to the real world entity validated, then
used in the protocol for validating domain control. But this still
only validates domain control, not legitimacy of domain authority.
> 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 :)
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
