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

[Gordon Bock]

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

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?


-Gordon


From: Ryan Sleevi <sleevi at google.com>
Sent: Friday, October 26, 2018 4:30 PM
To: Gordon Bock <gbock at microsoft.com>; servercert-wg at cabforum.org
Cc: 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 7:04 PM Gordon Bock via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
Hi All,
Microsoft performed an assessment of the “_” in domain names and our data points to  > 600 organizations globally (including Fortune 500, governments, and universities) who currently use an “_” in the domain name.   This is a large customer impact without a clear security enhancement.   We DO NOT believe that the data we evaluated from CT is comprehensive as it did not include DNS services specifications (eg. “_SIP”, “_TCP”, etc.) specified in documentation used by Microsoft as well as other software companies who produce products that require specified DNS Services (example; Lync, Skype, etc.).  Since these services are not consumed by browsers but rather dedicated clients we believe that many of these certificates are not recorded in CT logs.

Hi Gordon,

I'm afraid there's been some misunderstanding. This information is recorded in CT logs. Browsers don't log certificates themselves - a variety of tools, ranging from Censys (doing Internet- and service-wide scans), CAs that have logged their complete issuance activities, search engines, and researchers have all logged.

For example, the DNS service description was considered in the analysis, and there were entries that were captured.

https://docs.microsoft.com/en-us/lyncserver/lync-server-2013-dns-summary-single-consolidated-edge-with-private-ip-addresses-using-nat<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Flyncserver%2Flync-server-2013-dns-summary-single-consolidated-edge-with-private-ip-addresses-using-nat&data=02%7C01%7Cgbock%40microsoft.com%7Ce38c3d81ffa34e48230e08d63b9b0774%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636761934416299879&sdata=irwwXURXDO4CYvetjGd5r%2FkAPdjgWGWKM%2F5EI%2BDPBqQ%3D&reserved=0>

An argument could be made that if implemented end customers could purchase wildcard certificates.  However, many consider wildcard certificates to be a security risk, which is why CAA records allow for their exclusion.  For this reason Microsoft believes that wildcard certificates should not be a solution that is encouraged.   Additionally, the use of “_” is not prevented/discouraged by DNS providers nor web browsers.

This is not correct. As noted, this issue arose through bugs in Microsoft's DNS implementation, which propagated through the ecosystem. Multiple browsers have been working to resolve this issue. The use of underscores has created security issues in other spaces - such as the processing of IDNA encoding, as previously discussed. The failure to properly handle this has created security bugs requiring redefining the IDNA processing model.

Finally, CAA records allow for the independent restriction of wildcards, which is true, but that should not be seen as a core motivation for CAA to permit independent exclusion. As the discussion in the recent Shanghai F2F captured, this functionality can also be accomplished by working with the CAA enumerated in the CA record.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181027/aa381883/attachment-0001.html>