[cabfpub] Ballot 184 - SRVnames

[Ryan Sleevi]

On Thu, Oct 19, 2017 at 11:25 AM, Gervase Markham via Public <
public at cabforum.org> wrote:

> On 19/10/17 15:44, Jeremy Rowley wrote:
> > This seems to indicate SRV restrictions are something new compared to
> domain
> > name constraints. I suppose it's largely up to UA's implementing the RFC
> at
> > this point.
>
> Do we know anyone who has?
>
> Is strikes me (at first glance, and perhaps someone more technical will
> tell me why this is actually a terrible idea) that making DNS name
> constraints apply to the DNS portion of SVRNames in implementations
> might solve a lot of the problems with "missing restrictions" that we
> are otherwise going to have.


There are two approaches to doing subject name validation (in an RFC 6125
sense):

- Option 1: The API contract of your (hopefully RFC5280) path validator
provides the hostname-to-be-verified as well as the presented chain (to do
path building and/or validation on)
  - In this scenario, it's possible to extend the internal library to apply
the constraints you mention, although this violates the semantics of
RFC5280 (that is, it'd be a non-standard deviation)
  - Examples of this pattern include Security.framework on macOS and CAPI2
on Windows.
  - One notable challenge with this is that existing APIs would have to be
extended. This is because they presently take a mostly opaque-hostname
(assuming that it will be in the 'host' form extracted from a URL) and
determine what the appropriate SAN to match against based on the format of
the name. That is, some APIs will see if the hostname parses as an IP
literal and match against an iPAddress SAN, otherwise match against a
dNSName SAN. An SRVName would be indistinguishable from a DNSName, so the
API would need to be extended to indicate what the caller's intent was and
what service name they're attempting to match against.

- Option 2: The API contract is such that you use an RFC5280 path
validator, and then extract the SANs at an application level to perform
matching.
  - In this scenario, you call into an opaque 5280-box, and then if things
validate, you can reliably use the extracted SANs.
  - Examples of this pattern include many programming languages' libraries
(e.g. PHP, Python) and applications based on Open/Boring/LibreSSL
  - In this scenario, to support the solution you describe, each of these
languages would need to implement their own support for nameConstraint
parsing to extract the effective DNSName constraints from the validated
chain, and then see whether or not those constraints interact with the
SRVNames.

While this may seem appealing, https://nameconstraints.bettertls.com
demonstrates many implementations' challenges in having commonNames subject
to the dNSName or iPAddress name constraints - and the security risks
created - so one might assume the same situation would be prevalent,
especially for Option 2-style implementors. That's not to say it's
impossible - just that it adds considerable complexity.

There has been various interest in the past in exploring the functionality
of nameConstraints in particular to support such extensions. One
consideration would be the introduction of an (optionally-critical) new
extension that indicates whether nameConstraints behave as specified in
5280 (a blacklist - that is, everything not specifically enumerated is
permitted) to a new form of whitelist - in which only the names that are
constrained are permitted. The behaviour of such an extension would work as
follows:
- If marked non-critical, implementations which don't recognize this
extension would behave as 5280
- If marked non-critical, Option 1 implementations which recognize this
extension can reject certificates that contain other name types that are
not constrained, whether or not they recognize the underlying name type.
- If marked non-critical, Option 2 implementations which recognize this
extension can scan the extensions in the verified chain and determine a
non-overlapping set of nameConstraints, without having to fully reimplement
nameConstraint logic
- If marked critical, implementations which don't recognize this extension
would reject the chain (which would be the intended behaviour, as part of a
security-critical restriction)
- If marked critical, Option 1 implementations would work as if non-critical
- If marked critical, Option 2 implementations would likely fail to work,
due to the underlying 5280 validation library failing to detect this
extension

In any event, that at least hopefully captures the challenge, and why the
'simple' solution is likely not as simple as it appears.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171027/d8aecbd1/attachment-0003.html>