Subject: Re: [dbound] Some work that will probably hit dbound sooner rather than later

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jun 2015 12:33:11 -0400

On Fri, May 29, 2015 at 05:08:24PM -0400, Jeffrey Walton wrote:
> 
> By the way, the IETF appears to claim *.COM, *.NET etc is valid.

They're perfectly legitimate wildcard names.  That's at bottom the
problem we have to solve: DNS names do not carry semantics.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Thu, 04 Jun 2015 18:39:25 +0000

> problem we have to solve: DNS names do not carry semantics.

True -- but people are going to /continue/ to assume that they do, and we
are going to have to keep reminding them, and ourselves, that they do not.

A bunch of logical people recently paid surprisingly large amounts of money
for certain strings, like .baby and .app when they could have saved much of
this by instead using e.g wefddewrwtygf.net and h5y64tegh.org.

Yes, this isn't actually whether or not the names carry semantics or not,
but humans seem to naturally assume things from the labels, and it is hard
to stop this...

W

>
> A
>
> --
> Andrew Sullivan
> [email-masked]
>
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jun 2015 17:06:39 -0400

> are going to have to keep reminding them, and ourselves, that they do not.

That will be a waste of time.  Remind people their beliefs are false
all you like.  They will believe them even harder.

Instead, what we need is a mechanism by which such semantic intentions
can be captured in a way that they can be communicated reliably.  If
we don't achieve that, then we won't have addressed the problem this
WG is supposed to solve.

(Which of course raises the fact that I haven't given the problem
statement a good read.  Sorry, I've been submerged, but I hope to get
to it this week.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 4 Jun 2015 18:21:36 -0400

> problem we have to solve: DNS names do not carry semantics.
Maybe I'm missing the point... About all I would claim is they are
well formed regular expressions, so they should not crash the program
using them.

Within context, there's nothing valid about them for use in PKIX
because no entity or organization controls the gTLDs in question*.
Here, the relevant gTLDs are *.COM, *.NET, *.ORG, etc. Its the
e-equivalent of swamp land in Florida.

The troubling part (I find) is folks are accepting them and citing the
IETF. I can't make a counter argument citing the IETF it because its
true. About the only thing I can do is cite the CA/B Forums Baseline
Document and plead to common sense. You can imagine how well the plea
to common sense goes over at times....

The CA/B Forums codified their exclusion in the Baseline Requirements.
See section 3.2.2.

Jeff

* Related, ICANN calls the vanity TLDs gTLDs, too. So I'm not sure how
to refer to them unambiguously here. Maybe gTLD (*.COM, *.NET), ccTLD
(*.UK, *.CN), and vTLD (*.GOOGLE and friends).

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2015 04:20:29 -0000

>true.

If they're citing the IETF, they are badly misrepresenting what the
IETF does and says.  Our standards say a lot about mechanism, and
generally nothing about policy.  So if someone were to publish a *.COM
record in the DNS (which happened a while ago), IETF standards say
what queries it matches, what the formats of the DNS packets are, and
so forth.  Similarly if an https server were to present a certificate
with a name of *.COM, IETF standards say what a browser would do with
that certificate.

None of that means that any of us think it would be a good idea to
publish either of those.  If you were to compose a death threat and
e-mail it to [email-masked], IETF standards also say how
that message would be routed to its recipient, but that doesn't mean
we think that would be a good idea, either.

If DBOUND is moderately successful, we may well come up with a way for
someone to publish boundary advice that could say that there's a
boundary above COM. so a *.COM certificate would be a bad idea, but
there's no boundary above BARCLAYCARD. so a *.BARCLAYCARD certificate
would be OK.

But it still won't be the IETF publishing that advice.  It'll be
someone else, using our standard for the format of the advice.

R's,
John

PS: Yes, that's a real TLD.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 01:12:10 -0400

> with a name of *.COM, IETF standards say what a browser would do with
Thanks John.

So we are clear... The actual argument is "The RFCs don't prohibit them."

RFCs like 5280 and 6125 prohibit other things, but not wildcards on
gTLDs like *.COM and *.NET.

Folks are taking that to be an implicit approval. And its not just one
set of folks. Its at least three or four different, disjoint projects.
They all came back with the same argument when I filed the bug
reports.

I understand the IETF does not approve or condone it. I can even cite
this thread now. Maybe it would be a good idea to codify it somewhere
so that its relevant to or within reach of PKIX.

Jeff

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2015 05:19:10 -0000

>So we are clear... The actual argument is "The RFCs don't prohibit them."

This is a fundamentally silly argument.  The RFCs don't prohibit
sending death threats either.  

When an IETF document says MUST or MUST NOT, that means "you have to
do this, or not do this, or you won't interoperate with other
software", a purely technical meaning.  There's no technical
difference at the protocol level between *.COM and *.BARCLAYCARD --
it's a policy difference, and other people set policy.

>They all came back with the same argument when I filed the bug

Sounds like ICANN, if reality and a business plan collide, reality
loses every time.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 5 Jun 2015 01:23:50 -0400

> gTLDs like *.COM and *.NET.

It also occurs to me that the authors of 6125 and several of the authors 
of 5280 are quite active IETF participants.  I'm sure any of them would be 
happy to write a note saying we wrote the RFCs and that's not what they 
mean.

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

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 01:25:00 -0400

> sending death threats either.

OK, agreed. Developers do unexpected things. Life is stranger than
fiction at times.

So what is the IETF going to do about it now that its aware of the behavior?

Maybe its not a DBOUND problem. Maybe this particular problem is a PKIX problem.

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 02:06:01 -0400

> sending death threats either.
My bad... It looks like the RFCs allow it.

>From https://tools.ietf.org/html/rfc6125#section-6.4.3:

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   portion contains the wildcard character '*' as part or all of a label...

>From RFC 1034, there's only one reserved label and that is the root.
>From https://tools.ietf.org/html/rfc1034#section-3.1:

    One label is reserved, and that is
    the null (i.e., zero length) label used for the root.

Jeff

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Jun 2015 11:45:20 +0000

>we don't achieve that, then we won't have addressed the problem this

What I would have written if I read faster.

The difference is that at the syntactic level (so to speak), *.com. is a
validly formed domain name and conforms to the protocol definition.  At
the policy level (the how we use the DNS), this is not "permitted" because
it causes (and it has been demonstrated to cause) operational havoc.

Remember, there's a distinction to be made between a protocol's definition
and the operational use of it.

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2015 16:56:47 -0000

>   portion contains the wildcard character '*' as part or all of a label...

Right.  A cert for *.sales.bigcorp.com or *.smallcorp.com is fine.  A
cert for *.barclaycard is probably fine.  A cert for *.com is not
fine.  But there is no technical difference among those, only a policy
difference.  We do technology, not policy.

We're certainly not thrilled when people make bad policies, but it's
not something we can prevent.

R's,
John

---

From: Peter Bowen <[email-masked]>
Date: Sun, 7 Jun 2015 08:35:23 -0700

> not something we can prevent.

6125 does leave open a number of wildcard options that could be closed
down via technology.  6.4.3 (1) and (3) could move to MUST NOT, which
would mean the only allowed wildcard name would be "*" as the first
label followed by LDH labels.  As section 7.2 calls out, there are
numerous issues with ambiguity when using labels that mix a wildcard
with other characters in a single label.

It doesn't solve the original issue (is *.<TLD> acceptable?) but would
help reduce the probability of accidental misuse in other situations.

Thanks,
Peter

---

From: "John R Levine" <[email-masked]>
Date: 7 Jun 2015 18:02:55 +0100

> with other characters in a single label.

Thanks for bringing this up, since this will be a problem for DBOUND. 
For actual domain names, the rules are clear that the single character "*" 
as the leftmost component is a wildcard, a * anywhere else is just a 
character, e.g., the name a*.example.com only matches the name 
a*.example.com where that * is a literal character.  See RFC 4592.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Jun 2015 13:01:12 -0400

> and the operational use of it.

Yes, and what I've been arguing now for several years is that the
basic problem here is the lack of a mechanism by which the operational
policies can be expressed.  Instead, people try to read the policy off
the point in the hierarchy, and the PSL is the workaround for "where
in the hierarchy do you do that?".  I think the WG should try to
provide a way of doing this more reliably.

A

-- 
Andrew Sullivan
[email-masked]