[Servercert-wg] [EXTERNAL]Re: [cabf_validation] Underscores, DNSNames, and SRVNames

[Gordon Bock]

While we can certainly debate on how complete the corpus is for the CT logs, our objection is based on the > 600 organizations which are returned in existing telemetry which have “_”’s in the SANs.  While we agree that conformity is an issue, we believe it should addressed in a manner that minimizes impact to corporations, governments, and public institutions.  Using our CA’s to enforce conformity is a disruptive approach to conformity.  On this topic the practical costs outweighs the theoretical benefit.  These costs neither Microsoft nor Google would need to bear.  A less disruptive approach would be through browser enforcement.  Many organizations who leverage “_”’s have likely operated for many, many years using systems that involve distributed “fat” clients that have nothing to do with a web browser.  In these cases there is a high cost of implementing this change.

Unfortunately Microsoft did not vote on Ballot 202 last year due to changes in our organization, however thank you Ryan for co-signing on that initiative which would have alleviated this issue.

-Gordon


From: Ryan Sleevi <sleevi at google.com>
Sent: Friday, October 26, 2018 6:53 PM
To: Gordon Bock <gbock at microsoft.com>
Cc: servercert-wg at cabforum.org; Wayne Thayer <wthayer at mozilla.com>; Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabf_validation] Underscores, DNSNames, and SRVNames


On Fri, Oct 26, 2018 at 9:40 PM Gordon Bock <gbock at microsoft.com<mailto:gbock at microsoft.com>> wrote:
Hi Ryan,
Thank you for your comments.

While you raised interesting points of reflection on the corpus of CT, bugs in Microsoft’s implementation of DNS, and how browsers have worked to resolve systemic issues due to Microsoft implementation decisions these topics are less relevant on how to move forward.

Considering that the objection is based on the data being incomplete, I tried to show how that's not accurate. CAs can (and certainly have been repeatedly) encouraged to log their full corpus' to CT. Indeed, academic research such as http://www.icir.org/johanna/papers/imc16perspectives.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.icir.org%2Fjohanna%2Fpapers%2Fimc16perspectives.pdf&data=02%7C01%7Cgbock%40microsoft.com%7C1455f260b5464395344d08d63baef624%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636762020044252637&sdata=ohll80diteSdMfl6CZPZzN9MaFlVRjYLDjbAAagqBt8%3D&reserved=0> have shown it to be a reflective corpus.

Thus, if the view is that there is stuff not disclosed, I think the burden is on Microsoft to demonstrate that, as CAs can (easily) remedy that.

  Microsoft is not alone in specifying “_”’s in DNS Services, there are other large software vendors with important product installations that both use and specify “_”’s for DNS Services for product implementations.

I think there's some confusion here. The examples you cited are about DNS service discovery, which use underscore labels for purposes other than A records (where underscores are forbidden). Earlier in the thread, I discussed and provided the relevant specifications that discuss this - how even UTF-8 is permitted in the DNS records. None of these, however, are valid for hostnames - that is, A and AAAA records.

Indeed, in the example of Microsoft Lync, it observes the XMPP specification for service discovery and verification, which makes use of the SRVName. These cannot be used for publicly trusted CAs, and it sounds like a security bug in Microsoft's XMPP implementation if Microsoft is validating this names against the DNSName. You may wish to discuss this with your security teams to determine if your XMPP implementation is conforming to spec, especially since Microsoft authored the SRVName specification for certificates used by subsequent versions of XMPP.

In regards to the IDNA security risk, you mentioned “failure to properly handle [underscores] has created security bugs requiring redefining the IDNA processing model”.  It sounds like any risks to IDNA introduced by “_”’s has already been mitigated.

It has not, however, mitigated the risk from the ecosystem from spec-conforming implementations assuming invariants that are not met. For example, certain efforts related to the Web Platform were forced to be redesigned as a consequence of the underscore violation (that is, a spec known as 'suborigins', which improved the Web Security Model).

The continued use of underscores, in their spec-violating form, highlights the ongoing harm caused as communities, including those at Microsoft, make assumptions about the well-formedness of hosts that creates issues for implementation, deployment, interoperability, and security.

Are there any unmitigated security issues related to the continued use of “_”’s that would be best handled by the CA’s (who issue SERVERAUTH certificates consumed by both browsers and other client applications) vs. the browser itself?

This is a somewhat surprising argument for someone from Microsoft to make. Microsoft has historically been a champion of spec conformity as a way of mitigating security issues that result from spec and implementation misalignment, given how such issues have been such a rich source of bugs. I would hope we could agree that, regardless of known issues, the fact that we've had repeated past issues is sufficient demonstration that the purpose is fundamentally unsound.

The suggestion to kick this to the IETF to debate is equally not a productive one, in that this issue has been reviewed and relitigated, and the language stands. I provided references to the work in RFC 7719 (informational), and its subsequent work in drafting a BCP in https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dnsop-terminology-bis&data=02%7C01%7Cgbock%40microsoft.com%7C1455f260b5464395344d08d63baef624%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636762020044262649&sdata=XRX2BWnRR4PPjUjUZnvj5Jmk3mqUnx3zXkA8to5pOEk%3D&reserved=0> , maintain the assertion - and the grammar - derived from RFC 1034 and RFC 1123, as captured in "Host name". It's not for lack of consideration either.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181027/97accdb9/attachment-0001.html>