Subject: [Dbound] Are there any deliverables?

From: Jeffrey Walton <[email-masked]>
Date: Thu, 3 Jul 2014 17:41:33 -0400

Looking through the archive, Dbound appears to be relatively new. Has
the group produced any deliverables? If so, where are they?

Sorry to have to ask. I'm facing hostname matching/verification checks
for X509 certificate (not cookie matching), and I don't want to hack
up Mozilla's PSL (been here, done that). I'm looking for a more
disciplined approach this time around.

Thanks in advance.

---

From: Joe Abley <[email-masked]>
Date: Thu, 3 Jul 2014 17:48:11 -0400

Hi Jeffrey,

> disciplined approach this time around.

As I understand it, dbound has held a BOF but is not a working group, and hence has no charter or milestones.

I am aware of some work relating to PSL evolution going on in a couple of quiet corners, but nothing that has yet yielded any public results.

There are a couple of Internet-Drafts that could be used as part of a migration strategy from the currently-maintained PSL to something better in the future, but nobody (to my knowledge) has suggested out loud a migration strategy of any kind.

  http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01
  http://tools.ietf.org/html/draft-levine-orgboundary-02

I think it would be useful if you could talk more about your particular problem statement, though. If chartered, a future dbound working group will need all the problem statements it can get.

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Jul 2014 18:10:40 -0400

> I think it would be useful if you could talk more about your particular problem statement, though. If chartered, a future dbound working group will need all the problem statements it can get.

over on the w3c's webappsec list, there was a mention recently of the
public suffix list in the context of Content-Security-Policy (CSP) and
Cross-Origin-Resource-Sharing (CORS).  I think the feeling of the group
was that they didn't want to encumber those standards with the machinery
of the PSL, ultimately.  But it might be worth prodding that community
for more concrete problem statements about what kind of administrative
bounds they would be interested in.

	--dkg

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Jul 2014 18:20:03 -0400

> I am aware of some work relating to PSL evolution going on in a couple of quiet corners, but nothing that has yet yielded any public results.

Well, there was a design team formed, but they don't seem to have said
anything since.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 3 Jul 2014 22:56:14 -0000

>Well, there was a design team formed, but they don't seem to have said

Most of us on the design team met during the ICANN meeting, and decided
to try and deliver a draft that at least sets out the list of problems
that we think that DBOUND might address.

The issue we're stuck on (as Andrew knows but other readers may not)
is that people use the PSL for a variety of applications with subtly
but importantly different semantics.  A replacement design that would
work well for one often would work poorly or not at all for another,
and we've made no progress figuring out which problem(s) we're trying
to solve.

So as a first step, we'll try and describe all the problems we haven't
solved yet.

We'll probably do a bar BOF in Toronto, since Toronto is reputed to
have many bars.  Andrew may be able to offer insight here.

R's,
John

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 3 Jul 2014 19:22:23 -0400

Hi Joe,

> I think it would be useful if you could talk more about your particular problem statement, though. If chartered, a future dbound working group will need all the problem statements it can get.
My use case is rather dull. I'm working with a library, and I need to
connect to a server. For example, I want to connect to
www.example.com, and ensure one (or more) of the DNS names in the
certificate match the server I was attempting to connect to.

The expected positive case is I go to www.example.com, and the
certificate's SAN is www.example.com or *.example.com. In this case
the library returns SUCCESS for Match(servername, certificate).

The somewhat undesirable positive case is I connect to
www.example.com, and the certificate's CN is www.example.com or
*.example.com. Its somewhat undesirable because using using CN for DNS
names is deprecated by both the IETF (RFC 6125) and CA/B Forums
(Baseline Requirements). In this case the library returns SUCCESS for
Match(servername, certificate).

One of the negative cases that has me concerned: I connect to
example.com, the certificate has a SAN (or CN) of "*.com", and the
verification succeeds. Intuitively, we know that no one entity is
responsible for all of *.COM, yet many libraries don't fail the check
because its not explicitly prohibited in an RFC (like 5280 or 6125).

Here's another negative case that has me concerned: I connect to
www.example.com, the certificate has a SAN (or CN) of "www.*.com", and
the verification succeeds. Again, many libraries don't fail the check
because its not expressly prohibited in an RFC (like 5280 or 6125).

Finally, here's the last negative case that has me concerned: I
connect to example.co.uk or www.example.co.uk, the certificate has a
SAN (or CN) of "*.co.uk" and "www.*.co.uk", and the verification
succeeds.

Some libraries have a "two label" rule, but the two label rule is not
enough to catch the ccTLDs.

Open questions for me, which I hope the Dbound group can help with:

    1) *.com (gTLD match)
    2) *.co.uk (ccTLD match)
    3) w*.example.com (prefix with wildcard)
    4) *w.example.com (suffix with wildcard)
    5) www.*.example.com (inner wildcard, not gTLD or ccTLD)

I know how to handle some of the items above, but I don't know what I
should do with others. And it would be nice to cite an RFC that brings
sanity back to matching *.COM and *.CO.UK.

What I don't really care about at the moment (and others likely do
care about): foo.wordpress.com versus bar.wordpress.com. I don't
really care if there are two different operators hanging off of
wordpress.com. If the owner of the domain wordpress.com states he/she
is responsible for *.wordpress.com (and offends foo.wordpress.com and
bar.wordpress.com), then that's between the owner of the domain and
the subdomain operators.

I can go into more details with example certificates (Example CA and
attack-enabled end-entity certs) and code for a number of libraries
like .Net/C#, Cocoa, CocoaTouch, GnuTLS, Java, Python, PERL, and Ruby.
I should have some code for OpenSSL soon (hostname matching is being
cut-in as we speak; cf,
http://www.openssl.org/docs/crypto/X509_check_host.html).

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 3 Jul 2014 19:34:52 -0400

> bounds they would be interested in.
Thanks Daniel. I think I saw that thread (was that with Brad Hill?).

I think there's a potential political problem. Many libraries respect
the IETF, but hold the W3C is less esteem. So if the W3C published
something, then some popular libraries might be less willing to adopt
it compared to an equivalent document from the IETF.

My observations could be wrong about libraries and the W3C. When I use
a library to connect to a public website, the certificate was likely
issued under CA/B Baseline Requirements (or EV Guidlines). However,
the libraries refuse to validate them under the requirements they were
published, and choose to validate them under somewhat less specific or
more permissible standards (cf., allowable Key Usage and Extended Key
Usage combinations specified in RFC 5280).

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 3 Jul 2014 19:53:57 -0400

> work well for one often would work poorly or not at all for another,
Yeah, I've felt that pain when using the PSL for validating hostnames
in certifcates.

I think the solution would likely include a few profiles. For example,
DBOUND would have a base set of requirements. Those interested in
certificate hostname matching would get additional refinements. A
library providing a DBOUND implementation would allow the caller to
select the profile. Similarly, the Cookie/PSL case would have its own
separate profile, and a library would allow it to be selected when the
caller is similar to a browser.

The PSL is a list of entries (for lack of a better term) that are
black listed. Some entries are negatives, so they effective become
white listed. From working with the list in the past, its my
observation that there are three types of entries: gTLDs, ccTLDs,
"effective" TLDs or effTLDs, and Domains.

To bring them together, the CERTIFICATE_PROFILE would consider gTLDs,
ccTLDs and Domains. The COOKIE_PROFILE would consider gTLDs, ccTLDs,
effTLDs and Domains. Another profile of interest might be an
INTERCEPT_PROFILE, which allows *.COM (et al) matching for an
organization running an interception proxy.

> and we've made no progress figuring out which problem(s) we're trying
Ah, OK. I can give you the use cases I am familiar with. But they are
not sexy like the WWW folks want or have.

Jeff

---

From: "John R Levine" <[email-masked]>
Date: 3 Jul 2014 20:01:03 -0400

> I think the solution would likely include a few profiles.

The issues look deeper than something you could solve by one approach with 
profiles.  They're questions like whether the model is everything is the 
same except for subtrees that are marked different, or everything is 
different except for subtrees that are marked the same.

> not sexy like the WWW folks want or have.

I think we have a pretty good list of problems.  Let me see if I can help 
get a draft out and see if we missed anything.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 3 Jul 2014 20:36:20 -0400

> get a draft out and see if we missed anything.
Yes, please.

Also, I'm not sure about this from draft-sullivan-domain-policy-authority-01:

   Historically, policies were sometimes based on the DNS tree.  Early
   policies made a firm distinction between top-level domains and
   everything else; but this was also too naive, and later attempts were
   based on inferences from the domain names themselves.

I think the distinction is going to be one part of the solution.
There's no reason non-browser software should be matching "*.com" and
"*.co.uk" by default (and friends like "www.*.com" and "www.*.co.uk").
If you asked 100 developers if that's what they wanted, I would wager
the majority would not want the feature (and be surprised it was
happening).

Jeff

---

From: "John R Levine" <[email-masked]>
Date: 3 Jul 2014 21:17:05 -0400

> I think the distinction is going to be one part of the solution. ...

That's just one approach.

Regards,

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Jul 2014 21:41:12 -0400

>> I think it would be useful if you could talk more about your particular problem statement, though. If chartered, a future dbound working group will need all the problem statements it can get.

Another place where the idea of administrative boundaries in the DNS has
come up recently is in the certificate-transparency (CT) project, which
is currently under the auspices of the IETF's trans working group.  In
particular, there is a tension in CT between zones that must be publicly
logged in full (e.g. .com and .co.uk) and subordinate zones that have an
interest in not being publicly enumerable.

For example: the administrators of the example.com zone have a
legitimate interest in ensuring that the operators of .com do not
produce any extra certificates in the example.com zone which were not
authorized by the example.com administrators.  But they might not want
to advertise every single host in the example.com zone (for the same
reason that people don't offer promiscuous axfr).

So the CT notaries should be willing to log pre-certificates that name
<PRIVATE>.example.com, but they should not accept (or rather, CAs should
not submit) certificates that name <PRIVATE>.com.

The administrators of the example.com zone can monitor the public logs
and look for all <PRIVATE>.example.com certificates, and they know for
sure whether such a certificate was issued under their auspices.  But
they cannot know whether any given <PRIVATE>.com certificate was issued
within their zone, so they have no way of confirming (or refuting) that
a misissuance has taken place.

	--dkg

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Jul 2014 13:01:48 -0400

> have many bars.  Andrew may be able to offer insight here.

Supposing I were able to suggest such a bar, when are people likely to
be available?  I currently still appear to have part of Sunday evening
after the reception open, and I can think of a place not terribly far
from the meeting hotel that, on Sunday night, might actually be able
to accommodate a crowd of us such that we could have a bar BoF in a
bar.  I might even be willing to buy a whiteboard and easel to cart
along.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2014 17:04:40 -0000

>from the meeting hotel that, on Sunday night, might actually be able

I'm driving up, I can be there whenever I need to be.

R's,
John

---

From: Gervase Markham <[email-masked]>
Date: Mon, 07 Jul 2014 13:44:39 +0100

On 04/07/14 00:22, Jeffrey Walton wrote:
> responsible for all of *.COM,

...and the PSL is the best effort currently available to help a computer
understand what you know "intuitively". :-)

 yet many libraries don't fail the check
> because its not explicitly prohibited in an RFC (like 5280 or 6125).

If you come across such a certificate, send it to us, and we'll give the
CA a serious beating.

> because its not expressly prohibited in an RFC (like 5280 or 6125).

All modern browsers don't allow wildcards except in the terminal
position. I don't know of any libraries which do allow this; can you
name some?

> enough to catch the ccTLDs.

Which is why browsers gave up on that rule :-)

Gerv

---

From: Rick Andrews <[email-masked]>
Date: Mon, 7 Jul 2014 12:57:59 -0700

Gerv, Microsoft's SChannel allows w*.example.com and ww*.example.com.

http://support.microsoft.com/kb/258858

-Rick

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]] 
Sent: Monday, July 07, 2014 5:45 AM
To: [email-masked]; Joe Abley
Cc: [email-masked]
Subject: Re: [Dbound] Are there any deliverables?

...

All modern browsers don't allow wildcards except in the terminal position. I don't know of any libraries which do allow this; can you name some?

...

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Mon, 07 Jul 2014 21:01:15 +0100

> http://support.microsoft.com/kb/258858

Wow. Didn't know that. Thanks :-)

Gerv

---

From: Jothan Frakes <[email-masked]>
Date: Mon, 7 Jul 2014 14:03:52 -0700

Wow, Rick, I did not know that about IE.  It appears to allow "to end of
line".  This makes some sense from a practical standpoint, as it would
address many load-balancing  scenarios.

Jothan Frakes
Tel: +1.206-355-0230

On Mon, Jul 7, 2014 at 12:57 PM, Rick Andrews <[email-masked]>
wrote:

> All modern browsers don't allow wildcards except in the terminal position.
> I don't know of any libraries which do allow this; can you name some?
>
> ...
>
> Gerv
>
>
> _______________________________________________
> Dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 7 Jul 2014 18:28:50 -0400

> http://support.microsoft.com/kb/258858
So will OpenSSL when hostname verification is added in 1.1.0. Hostname
matching and verification is not currently available/performed in
OpenSSL 1.0.2 or down level. (I hope that it was not a shock to the
readers ;)

At the moment, OpenSSL's pattern matching behavior is to allow the
asterisk as a prefix or suffix in the label; and allow a asterisk in
an arbirary location. The default behavior must be modified with
X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS (to stop 'w*' and '*w'). I don't
believe there's anything to suppress a match in an arbitrary location
(i.e., 'www.*.co.uk').

Oh, and the APIs to set the flags is *not* supposed to be called by
applications ;)

See http://www.openssl.org/docs/crypto/X509_check_host.html. And a
discuassion at "Hostname checking and X509_check_host",
http://marc.info/?t=140436243100002&r=1&w=2.

Jeff

---

From: Gervase Markham <[email-masked]>
Date: Tue, 08 Jul 2014 10:47:25 +0100

> believe there's anything to suppress a match in an arbitrary location

The CAB Forum Baseline Requirements define a Wildcard Certificate as:

"A Certificate containing an asterisk (*) in the left-most position of
any of the Subject Fully-Qualified Domain Names contained in the
Certificate."
https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_8.pdf

So my understanding is that issuing certs which have wildcards in
positions other than "the (entire) left-most position" is not permitted
under the BRs, and so as time goes on and older certs expire, should not
be seen on the publicly-trusted secure web.

Gerv

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 8 Jul 2014 10:37:41 -0400

> be seen on the publicly-trusted secure web.
No argument from me. As a matter of fact, I of make the same argument:
CAs are issuing in accordance with Baseline Requirements (and the EV
Guide).

I'm not sure if it is a education or political problem. Do folks not
know what the CAs are issuing against? Or do folks not recognize the
other bodies (like CA/B or W3C). Or maybe they just don't care...

Jeff

---

From: manning <[email-masked]>
Date: Mon, 7 Jul 2014 13:28:08 -0700

its -lots- of fun.   Hotz & I did this {regular expressions in DNS labels} last century.  
gave many people headaches.

/bill