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

[Wayne Thayer]

On Tue, Oct 23, 2018 at 6:33 AM Ryan Sleevi <sleevi at google.com> wrote:

>
> 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?
>
>
Given the data that you shared, please explain how you reach the conclusion
that there is zero "pain" for Subscribers?

>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.
>
> I am explicitly attempting to prevent this type of behavior by requiring
that all certificates with a lifetime > 30 days be revoked prior to 1-June.
Are you dismissing revocation as an effective tool for blocking the use of
these certificates (presumably they would need to be added to a CRLSet), or
is there some other problem with this approach?

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.
>
> Given that the impact is so small, perhaps a better solution is to stop
debating this and for you to file a bug to block these certificates in
Chromium. Seriously - that would satisfy my primary goal here.

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 sounds like you are focused on the behavior of the CAs, and I'm focused
on the behavior of the Subscribers. Thinking about the SHA-1 sunset, I
don't want Subscribers to have any hope of getting an exception.

>
>> 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"
>

MY goal is to find a compromise - Your goal is not clear to me, and you
didn't answer my request for specific guidance. Would a ballot that
"immediately" forbids issuance of these certificates with validity periods
of greater than 30 days be the basis for an acceptable compromise? If not,
is that because you don't believe that any acceptable compromise exists?

>
> 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.
>

To the extent that a whitelist benefits CAs who have continued to - or
recently discontinued - issuance of these certificates, I agree that a
whitelist is biased and thus shouldn't be pursued.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181023/4191a19e/attachment-0001.html>