[Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

[Ryan Sleevi]

On Mon, Oct 22, 2018 at 1:03 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> On Mon, Oct 22, 2018 at 12:18 PM Ryan Sleevi <sleevi at google.com> wrote:
>
>>
>> On Fri, Oct 19, 2018 at 1:59 AM Wayne Thayer <wthayer at mozilla.com> wrote:
>>
>>> Here is a draft ballot that reflects my understanding of the outcome of
>>> our discussion in Shanghai. I would appreciate your review of the language
>>> for any logic gaps and for clarity. I'm also looking for two endorsers.
>>>
>>> - Wayne
>>>
>>> Ballot SC## - Sunset of Underscores in DNSNames
>>>
>>> Purpose of Ballot
>>>
>>> Ballot 202 included a provision creating a permanent exception
>>> permitting the underscore character to be used in SAN fields of type
>>> DNSName. Since that ballot failed in 2017, the practice has continued
>>> despite being non-compliant with RFC 5280. This ballot creates a brief
>>> sunset period intended to allow Subscribers who are relying on FQDNs
>>> containing underscores to transition away from them, either by changing the
>>> name or deploying a wildcard certificate.
>>>
>>> The following motion has been proposed by Wayne Thayer of Mozilla and
>>> endorsed by xxx of yyy and xxx of yyy.
>>>
>>> --- MOTION BEGINS ---
>>> Add the following language to BR section 7.1.4.2.1 (Subject Alternative
>>> Name Extension):
>>>
>>> Prior to February 1, 2020, certificates containing underscore characters
>>> in domain labels in DNSName entries MAY be issued as follows:
>>> * DNSName entries MAY include underscore characters (“_”) in domain
>>> labels such that replacing all underscore characters with hyphen characters
>>> (“-“) would result in a valid domain label, and;
>>> * After May 31, 2019, such certificates MUST NOT be valid for longer
>>> than 45 days.
>>>
>>
>> This doesn't seem to match the discussion in Shanghai, particularly
>> around the dates.
>>
>> Yes, we discussed 30-day durations in Shanghai. I increased it to 45 days
> based on feedback from CAs stating that the same enterprise subscribers who
> will need time to migrate aware from labels containing underscores also
> have bureaucratic change management processes. I don't have a lot of
> sympathy for that argument and am happy to go with 30 days, but I also feel
> that 45 day durations create enough pain to achieve the goal of pressuring
> organizations to move off of these certificates prior to the 2020 deadline.
>

Given the data I've shared, do you feel that it's still an accurate
statement to suggest there's any "pain" at all, or that there are any
bureaucratic change management processes involved?

>From sampling even the set of names involved - that is, certificates that
historically existed - it is actually the case that many of these
certificates are no longer in use, because they've adopted DNS hosting
providers, such as Cloudflare, that fail to resolve such names.


> The suggestion here was an immediate migration to 30 day certificates
>> (where "immediate" here can be read w/in 30 days of the ballots IP review),
>> and a revocation period 6 months after (which would put it around April).
>>
>> That's not what I was thinking during the discussion. Again, my primary
> goal is to make a clear statement of policy in the BRs. My secondary goal
> is to provide subscribers who don't recognize this as a problem some time
> to transition. I believe my proposal achieves the second goal better than
> an immediate shift to 30-day validity periods.
>

I think we disagree, then. By failing to adopt an immediate sunset - which
I believe the data does not support - this encourages CAs to reissue
certificates with the prolonged period sooner for their customers, "just in
case". This then creates more migration pain, as customers will have 2+
year certificates, and fail to actually transition until their current
certificate expires.

This can be seen repeatedly each time the ecosystem has attempted a sunset
- SHA-1, 1024-bit keys, the transition to requiring Symantec to use
CT-logged certificates, the transition for the ecosystem to use CT-logged
certificates. We see, in the final days before the sunset, a rush to keep
everyone existing still happy, even if it's acknowledged that new customers
will be turned away.

While this might be thought of as "customer friendly", it in fact only
delays the customers actual communication and experiences with the CAs, the
awareness of a need to make a change, or the actual execution of this
change.

Indeed, from the time we've (recently) been discussing, the uptick in
issuance - even as some CAs, such as Comodo (third-largest historically in
issuance) have stopped - suggests that's exactly whats happening. Any
solution that fails to consider retroactive revocation is doing harm to the
ecosystem and the customers most at risk for needing a transition. Which,
again, based on the data, seems closer to a dozen organizations in
practice, if even that.


>
> The discussion in Shanghai similarly looked at whitelists as a further
>> mitigation.
>>
>> Yes, and I rejected that as unnecessarily complex. I would be happy to
> put in a requirement for CAs to warn subscribers that this practice is
> being deprecated, but I really don't see brand new uses of labels
> containing underscores as the problem. A whitelist also creates the
> impression that there will be an exception process - something I feel
> strongly that we should avoid.
>

Can you explain how we're discussing anything but that? We've expended
significant energy for what accounts for a dozen or so organizations. We
have data to know the scope of the problem and the impact, and its
practical reality.

Perhaps you can help me understand how this is different than, for example,
Symantec's issuance of multiple BR violating certificates -
https://bugzilla.mozilla.org/show_bug.cgi?id=966350 - and a process of
retroactive indulgences?


>
> It seems strongly anti-competitive, and against the security and stability
>> of the ecosystem, to adopt with the timing suggested. Every CA who declined
>> a customer's business on the basis of adhering to the requirements gets a
>> slap across the face for prioritizing compliance and security - in that
>> their competitors who repeatedly violated the BRs can potentially continue
>> to issue. Further, such a ballot would *encourage* more CAs to begin
>> permitting such certificates - precisely because it's now attractive and
>> blessed. This does not seem a right way to help maintain an ecosystem, and
>> would be disastrous to any other requirement - because it explicitly states
>> that continued misissuance will be rewarded.
>>
>> Yes, there is some moral hazard in addressing this situation as I'm
> proposing. However, I don't think that ignoring the real confusion that
> exists and doing nothing more than continuing to argue for how wrong it is
> will be very effective. If there is no BR amendment, I'm confident that
> we'll see misissuance of underscores in DNSNames for years to come.
>

I simply fail to agree here with this position, nor do I think any of the
discussion to date has provided any support of it. I would simply not
accept a claim from someone who said the same about "I'm confident that
we'll see misissuance of 1024-bit certificates for years to come" or "I'm
confident we'll see CAs failing to validate the domain name is owned by the
subscriber for years to come". It's fair to state it's a problem, but the
only reason this itself is a problem - compared to, say, default encoding
of bools, improper EKUs, invalid DNS names, etc - is because there has been
lax enforcement by browsers to the clear and unambiguous standards.

The statement that "It used to work" also doesn't fit with the policies
adopted by multiple browser programs, which forbid a number of practices,
even though they happened to "work" in their clients. A certificate issued
for "www..example.com" works in Firefox or Edge today - does that somehow
make it OK?

It's a fairly easy problem to correct, and is consistent with how the
ecosystem has corrected a number of other problems resulting from CAs
inability to follow the RFCs. The auditor qualifies the operations -
because it's clearly non-compliant with RFC 5280. The browsers complain
about the qualification. If the auditor fails to qualify, the community
points out the misissuance against RFC5280, and requires the CA to take
remediation steps, which almost invariably involves some first order
"pre-issuance linting", but with the amount of discussion on this issue, is
not really a justified excuse. CAs are notified by browser programs that
the process is a violation of RFC 5280. Any violations are treated just
like any other non-compliance - something that may result in the potential
distrust of existing certificates, the exclusion of including new roots,
the failure to grant EV, restrictions on new certificates, etc.

This is not a 'hard' problem by any means. I fail to understand the
hand-wringing, precisely because we have the data to state the nature of
the problem. I do see serious harm to the legitimacy of the Forum and the
trust and faith for its ability to actually develop self-governance
policies, however, from this very discussion itself. Because it shows very
clearly to some Forum members that certain browsers will inconsistently
enforce their policies, dependent on who it was who misissued and how much
they misissued, without any objective data to support any of the claims
made by CAs. And if that's going to be our approach, we shouldn't even both
having a CA/Browser Forum to begin with.


>
> Further, there's the very real question that these should be
>> qualifications on audits. There's no reason to believe they shouldn't have
>> been qualifications before, but such an exception seems to have the goal of
>> preventing such qualifications from appearing. This similarly seems to be a
>> slap across the notion of the Baseline Requirements being requirements,
>> since it would be granting retroactive acceptance.
>>
>> I really don't care if these are qualifications. Do you have a proposal
> for how that could be accomplished?
>

Put any dispensation about transitions into the Root Program Agreements.
Despite the discussion to date, no one has provided a reading of RFC 5280
that could be interpreted to permit it. These certificates are misissued,
and should have been revoked within 24 hours of issuance. I'm willing to
bet that there are responsive CAs who have historically issued, such that
many of the certificates I mentioned are already themselves revoked - or
the issuer is revoked.


>
> Finally, it doesn't set an actual sunset date for migration, and that
>> itself seems problematic. There's no reason or data to support the notion
>> that 4000 certificates - whose mere existence threatens the
>> interoperability of the ecosystem w/r/t TLS, the security of the ecosystem
>> w/r/t URL parsing and resolution, and the reliability of the Baseline
>> Requirements and the auditing profession - somehow justifies the need to
>> continue supporting such certificates beyond October 2019, at the latest.
>>
>
> Sure it does - the last valid certificate under my proposal expires on
> March 1, 2020.
>
> Again, I am hoping to find a compromise that definitively ends this
> problem. Unless you prefer the status quo, providing specific
> recommendations that would make my proposal more acceptable would be more
> helpful than continuing to point out all the reasons why you think it's bad.
>

I am simply at a loss how one can think there even needs to be a
'compromise' - particularly to 2020 - given the data provided. We're not
discussing unknown-unknowns. We've got fairly good visibility into the
problem, and can make concrete statements as to the impact and the
transition.

Of the issuer organizations that have issued more than 5 certificates,
here's what we see:

count issuer_organization
2108 Symantec Corporation
948 DigiCert Inc
198 GoDaddy.com, Inc.
198 GeoTrust Inc.
125 Entrust, Inc.
84 COMODO CA Limited
78 QuoVadis Limited
42 AffirmTrust
25 TERENA
25 Wells Fargo
24 行政院
19 Cybertrust Japan Co., Ltd.
16 Internet2
15 Starfield Technologies, Inc.

A full half of those certificates - 2108 from Symantec, 198 from GeoTrust,
total 2306 - will shortly be removed from the trust ecosystem. If we look
at the reminder, we see 948 for DigiCert, 213 for the combined GoDaddy
brands (GoDaddy and Starfield), 167 for the combined Entrust brands
(Entrust and AffirmTrust), and 84 for Comodo.  Comodo has already stated
they've stopped the practice.

And this is continuing to overstate the impact, as some organizations -
such as Wells Fargo - are not trusted by modern programs (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=896546 ) - others were not
"publicly" trusted at large - Internet2.

Whether we take the view that this was 'historically' confusing or is
'presently' confusing, it's pretty clear that the only confusion exists for
a certain subset of members. Plenty of others managed to avoid it, and the
data itself shows the scope of the 'problem' is not one that should take
years, let alone months, to resolve.

If the goal is to find compromise, then it seems more reasonable to focus
on "Which organizations cannot switch to a wildcard certificate tomorrow"

That subset shows its a far fewer set of names, many of which themselves
are no longer valid domains (demonstrably not in use nor possible to) and
makes it clear that we're spending all this time for a few dozen
organizations. Which is to say it's a whitelist, it's an exception process,
and it's one that directly benefits a few CAs and a few organizations, yet
with existential risk to the legitimacy of the Forum, the Baseline
Requirements, and the neutrality of the Forum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181022/59876874/attachment-0001.html>