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

Gordon Bock gbock at microsoft.com
Fri Oct 26 16:04:47 MST 2018


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.

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%7C11f8b6e1360546b9c07a08d63b95c987%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636761911856776014&sdata=KjDVnQCoLUhQmO1C%2Fz%2FHeJDv70routvi0bQMufUqk4Q%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.  In summary, it does not appear that the use of “_”’s is an issue for other important components of the Internet.  Microsoft concludes that preventing CA’s from issuing leaf certificates with an “_” would put an undue burden on our customers without a clear security benefit.

RECOMMENDATION
Microsoft would like to reevaluate ballot 202 submitted in 2017 that allows the use of “_” in leaf certificates.  Underscores should be explicitly allowed until the CABF can determine how the IETF would like to proceed.  If the IETF determines that underscores should be removed, then this body can move towards a reasonable deprecation schedule to ensure relevant documentation is updated and provide time for existing users to migrate.  If the timeframe for this effort is not conducive to members of this forum then we suggest that enforcement occur within the browser and not with CA’s to limit impact to other services that currently depend on the “_”.

Thanks,
-Gordon


Gordon Bock | Security Project Manager
Windows & Devices Group | Information Security
Governance Risk & Compliance
One Microsoft Way | Redmond, WA 98052
O: 425.707.2995 | M: 206.948.9114

[MSFT_logo_Gray DE sized SIG1.png]




From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Wayne Thayer via Servercert-wg
Sent: Friday, October 26, 2018 11:26 AM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabf_validation] Underscores, DNSNames, and SRVNames

Bruce - I understand your concern and respect Entrust's position, but I don't think it represents the best compromise with those who have taken a strong position against this practice, or the rough consensus I heard on yesterday's call. Specifically, I believe that some server operators will ignore this until we revoke their certs, and then argue that one month isn't enough time to make the required changes. I believe that more time between revocation and the final issuance is better.

I'm going to go ahead and begin the review period as-is.

Thanks,

Wayne

On Fri, Oct 26, 2018 at 11:06 AM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Hi Wayne,

We support the deprecation of underscore certificates. In fact, our plan will be to revoke all underscore certificates with more than 30 days validity on the proposed date of 15 January 2019 and discontinue issuance of underscore certificates on the same date.

However, we do feel that the schedule is very aggressive to allow CAs to ban the use of underscores, communication with Subscribers and allow Subscribers time to change domain names or policies to allow wildcard certificates. Further, we feel that the 30 day certificate will not be useful to our Subscribers and do not plan to implement this requirement.

We would request that the date of 15 January 2019 be moved out to 31 March 2019. This will allow for better response to the requirement of deprecating underscore certificates and still meet your full implementation deadline of 30 April 2019.

Thanks, Bruce.

From: Servercert-wg [mailto:servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>] On Behalf Of Wayne Thayer via Servercert-wg
Sent: October 25, 2018 4:50 PM
To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Subject: [EXTERNAL]Re: [Servercert-wg] [cabf_validation] Underscores, DNSNames, and SRVNames

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Here is an updated draft ballot that reflects discussion on the list and this morning's call.

It was pointed out that - even if the discussion period starts today and is kept to 7 days - this ballot won't become effective until roughly 8-December, and of course there are concerns with mandating revocations during holiday change freezes, so I moved the revocation date from 1-December to 15-January.

I also fixed the logic forbidding underscores when a wildcard can be used.

I'm still 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 April 1, 2019, certificates containing underscore characters (“_”) in domain labels in DNSName entries MAY be issued as follows:
* DNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;
* Underscore characters MUST NOT be placed in the left most domain label, and;
* Such certificates MUST NOT be valid for longer than 30 days.

All certificates containing an underscore character in any DNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.

After April 30, 2019, underscore characters (“_”) MUST NOT be present in DNSName entries.

--- MOTION ENDS ---

This ballot proposes a Final Maintenance Guideline. A comparison of the changes can be found at: <TBD>


The procedure for approval of this ballot is as follows:

Discussion (7-21 days)
Start Time: 2018-10-xx, 7:00 am Eastern Time
End Time: Not before 2018-11-xx, 7:00 am Eastern Time

Vote for approval (7 days)
Start Time: 2018-xx-xx, 7:00 am Eastern Time
End Time: 2018-xx-xx, 7:00 am Eastern Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181026/7749f436/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 1966 bytes
Desc: image003.jpg
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181026/7749f436/attachment-0001.jpg>


More information about the Servercert-wg mailing list