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

[Ryan Sleevi]

On Fri, Oct 26, 2018 at 9:40 PM Gordon Bock <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
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 , 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/20181026/c38eadd7/attachment.html>