Subject: [dbound] IETF 94 agenda posted

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Nov 2015 07:13:28 +0900

Colleagues,

Pete and I have had difficulty syncing up in recent weeks which led to
delays in deciding on an agenda.  So, with apologies to you all for its
tardiness, the agenda for our IETF 94 meeting has been posted:

https://datatracker.ietf.org/meeting/94/agenda/dbound/

We will say this at the meeting but also wanted to say it early as well for
those who will be remote:

We are concerned that the working group is still in a phase of discussing
the problem definition.  This is our second in-person meeting and we still
have no concrete milestones, and there hasn't been sufficient progress
since Honolulu in July to get us there.

We would like to come away from Tuesday's session with some deliverables to
which the working group is prepared to commit.  Failing that, we won't be
requesting any further in-person meetings (they are expensive and space is
in high demand) until committed milestones have been established.  The list
will of course remain active for the purpose of sorting that out.

-MSK, DBOUND co-chair

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2015 06:55:41 -0000

>the problem definition. 

Here are three problems:

* the browser cookie problem
* the CA name/wildcard problem
* the DMARC organizational domain problem

Here are three axes to characterize technical approaches

1) DNS vs. non-DNS
a) single boundary in a name vs. multiple
I) self publishing vs. third party

For example, the existing PSL is non-DNS, multiple boundary, third party.

This is not every possible problem and every possible axis, but I
think it's a large enough set that if we came up with an approach that
addressed all three problems, and we generally agreed that the point
on the axes meets people's practical needs, we could declare success.

If we came up with an approach per problem we might declare success
depending on how confident we were that the points on the axes were
the ones that people need.

R's,
John

---

From: Jothan Frakes <[email-masked]>
Date: Mon, 2 Nov 2015 10:17:18 +0100

> I) self publishing vs. third party
On the third of these, thinking root-down, where there is an authority
chain from a parent entity (in Delegation) to child, I am pondering is
"self-publishing vs third party" stretches to fit the status quo if there
is a concept of authoritative chain.

What I mean is that within the concept of "trust", if one were to pick
between "self published" and "third party", which would be more trusted?

Would the parent zone in DNS be "third party", for example?

The IANA public suffix list (which gets generated from the root zone) is a
"third party" list as it would relate to most everything with (perhaps
excluding .int or .arpa to be pedantic).

-- 

Jothan Frakes
Tel: +1.206-355-0230

---

From: "John R Levine" <[email-masked]>
Date: 2 Nov 2015 18:24:18 +0900

> is a concept of authoritative chain.

I'd say that was self publishing.  By third party I was thinking of 
someone like the group at Mozilla that maintains the current PSL.  Self 
publishing would be something like putting the info in a standard place in 
the part of DNS tree that the publisher controls.

> between "self published" and "third party", which would be more trusted?

That depends entirely on who the third party is and what we think of the 
entities publishing.

> excluding .int or .arpa to be pedantic).

IANA publishes a list of TLDs but that is extremely definitely not a 
public suffix list since, among other things, they make no assertion about 
the structure of the names underneath each TLD.

R's,
John

---

From: Jothan Frakes <[email-masked]>
Date: Mon, 2 Nov 2015 07:35:52 -0800

> the part of DNS tree that the publisher controls.
My point was that it is not a clear fit in either without using
subjectivity - and that subjectivity lends itself to softening the benefit
of the classification.

I respect where you see it as self publishing, and hold your opinion as
being a completely reasonable and a possible one that someone could come
to.  I can also see a reasonable person coming to a different conclusion in
how they would categorize it as I do, as a third party list.  The challenge
here is that it is neither your or my categorization being right or wrong
is the issue - the challenge is that we should help ensure that how it gets
categorized requires as little subjectivity as possible so that there is a
consistent and clear outcome.

> That depends entirely on who the third party is and what we think of the

Right - this is the subjectivity.  I think at the core of my comment on
this was 'authority' as part of trust of the list.   Which still might
prove to be subjective as well - or application/use/purpose dependant.

> the structure of the names underneath each TLD.
Completely hear you on the current state of that - yet unfortunately many
integrators and developers use the IANA list for what 'tis or 'taint a TLD
for validation purposes.

Anyway, I was more alluding to 'future state' of IANA PSL - I should have
probably been better about citing what the ICANN SSAC concluded with
respect to this so that it did not sound like I was proclaiming my opinion
on the IANA list in its current form to be fact.
https://www.icann.org/en/system/files/files/sac-070-en.pdf (see
recommendation 5 from ICANN's Security and Stability Advisory Committee
(SSAC) was that IANA create and distribute a PSL),

---

From: "John R Levine" <[email-masked]>
Date: 3 Nov 2015 09:28:11 +0900

> integrators and developers use the IANA list for what 'tis or 'taint a TLD

Please don't confuse public suffixes with TLDs. For example, .co.uk is a 
public suffix but not a TLD, while .bloomberg is a TLD, but it's not a 
public suffix.*

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

* - yes, I know it's in the PSL but that's due to the limits of the 
current text format, not because it's actually public.

---

From: Casey Deccio <[email-masked]>
Date: Mon, 2 Nov 2015 21:15:30 -0500

> between "self published" and "third party", which would be more trusted?
If I understand what you are saying, this is in part a question of
backwards compatibility.

draft-deccio-dbound-organizational-domain-policy [1] addresses this by
building a "policy-negative realm" into the top of the DNS hierarchy under
the _odup domain name, such that all names in the _odup DNS domain comprise
what is essentially equivalent to the current public suffix list.  This
makes it so one can effectively be generated by the other for a time. See
Section 5 for details.

> excluding .int or .arpa to be pedantic).

I'm not sure there is anything claiming to be a public suffix list from
IANA or how it could be generated from the root zone.  The root zone
contains delegations to top-level (i.e., single-label) domains; their
"public" or non-public status is not inherent in their name.

Casey

[1]
http://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/
(version
00)

---

From: Casey Deccio <[email-masked]>
Date: Mon, 2 Nov 2015 22:00:04 -0500

> * the DMARC organizational domain problem
+1

Solid examples.

I insert here a third category: "solution scope"

* hierarchical domain bounding
* cross-domain bounding

There was agreement in the working group meeting in Prague that both should
be considered.  But it's not to say that a single solution can/should
address both.

> For example, the existing PSL is non-DNS, multiple boundary, third party.

These are good.  Although I think the second item (single vs. multiple
boundaries) is probably moot since single *is* the current state of things
and thus really isn't an option for future solutions.  Also, because of the
"solution scope" category I added above, "single boundary in a name" or
"boundary in a name" at all might not make sense in some paradigms (e.g.,
the cross-domain).  Although, this is kind of a nit.

> on the axes meets people's practical needs, we could declare success.

+1

Casey

---

From: "John R Levine" <[email-masked]>
Date: 3 Nov 2015 15:24:08 +0900

> be considered.  But it's not to say that a single solution can/should

I know, but in view of the lack of progress I propose we limit the scope 
to hierarchies.

> Although I think the second item (single vs. multiple boundaries) is 
> probably moot since single *is* the current state of things and thus 
> really isn't an option for future solutions.

Really? Look in the PSL and you'll find com and compute.amazonaws.com and 
eu-central-1.compute.amazonaws.com.

R's,
John

---

From: "Hodges, Jeff" <[email-masked]>
Date: Tue, 3 Nov 2015 07:28:25 +0000

the below seems useful, thanks for writing it up.   I have an additional "problem" to add, below:

On 11/1/15, 10:55 PM, "John Levine" <[email-masked]<mailto:[email-masked]>> wrote:

Here are three problems:

*  HSTS & HPKP feature an "includeSubDomains" directive which means that the policy in question (HTTP Strict Transport Security, or HTTP Public Key Pining) applies not only to the hostname that declared the policy, but ALL subdomains thereof.

In terms of how a dbound solution might be applied here: It would be advantageous to be able to have it apply to all subdomains down the inverted domain name tree UNTIL a declaration of different policy realm is encountered.

HTH,

=jeffH

1) DNS vs. non-DNS

R's,
John

_______________________________________________
dbound mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dbound

---

From: Casey Deccio <[email-masked]>
Date: Tue, 3 Nov 2015 03:03:30 -0500

> I know, but in view of the lack of progress I propose we limit the scope

It works for me.  At the very least we shouldn't block one, waiting on a
silver bullet approach for both.

>> probably moot since single *is* the current state of things and thus really
>> isn't an option for future solutions.
>>
>
Yep, really :)

The effective outcome of any PSL lookup is the "public suffix" of the
name.  The algorithm is longest match [1].  That's why there's only one
possible organizational domain with the current DMARC algorithm, for
example.

Casey

[1] https://publicsuffix.org/list/

> [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 3 Nov 2015 17:07:35 +0900

> possible organizational domain with the current DMARC algorithm, for

Oh, in that case we agree.  By multiple I meant that there could be 
multiple boundaries in a path, not that any particular lookup would return 
more than one of them.

R's,
John

---

From: Gervase Markham <[email-masked]>
Date: Tue, 3 Nov 2015 09:18:24 +0000

> current text format, not because it's actually public.

Well, to be pedantic... it's more that we default to including new
gTLDs. If Bloomberg got in touch and told us that this wasn't a public
suffix, we could perhaps replace:

bloomberg

with

!bloomberg

Which would, I believe, according to the rules, encode the fact that
bloomberg was not a public suffix. Not sure how PSL-using software would
react to that, of course, as we've never had a rule like that before... :-)

Gerv

---

From: "John R Levine" <[email-masked]>
Date: 3 Nov 2015 18:27:40 +0900

> suffix, we could perhaps replace:

Hmmn.  For the new gTLDs, each application makes it clear who's going to 
accept registrations from other people and who's a closed vanity domain.

For bloomberg, for example, it's here:

https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/127

Section 18 of each application says who can register, in this case:

  Description of registration policies.  BIP will initially register
  .bloomberg domain names for Bloomberg Philanthropies for the use of, or
  in connection with, charitable campaigns and advocacy on public issues.
  In the future, BIP may also register domain names for other Bloomberg
  entities for commercial use.  In operating the .bloomberg gTLD, BIP will
  follow the policies and procedures required by the Registry Agreement.
  Registration of domain names in the .bloomberg gTLD will not be open to
  the public or non-Bloomberg affiliated companies.

I realize looking at all of the applications is tedious, but it's quite 
mechanical.

R's,
John

---

From: Francisco Arias <[email-masked]>
Date: Tue, 3 Nov 2015 09:38:04 +0000

New gTLD applications may not necessarily reflect what ultimately got
implemented. For the definitive answer the registry agreement page of each
TLD would do:

https://www.icann.org/resources/pages/registries/registries-agreements-en

Those TLDs that have Specification 13, e.g.,
https://www.icann.org/resources/agreement/bloomberg-2014-07-17-en has
https://www.icann.org/sites/default/files/tlds/bloomberg/bloomberg-spec13-1
7jul14-en.pdf There are a number of these so called “brand TLDs”.

Please let me know if there is interest in having a more automatable way
to discover this, e.g., by expanding http://newgtlds.icann.org/newgtlds.csv

Regards,

-- 
Francisco.

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 3 Nov 2015 08:14:22 -0200

The actual logic would be something like
- Has Spec 9 exemption but no Spec 13 -> Single use TLD
- Has both Spec 9 exemption and Spec 13 clauses -> Brand TLD

That might be useful to differentiate. 

Rubens

> On Nov 3, 2015, at 7:38 AM, Francisco Arias <[email-masked]> wrote:
>

---

From: Gervase Markham <[email-masked]>
Date: Tue, 3 Nov 2015 11:20:20 +0000

> to discover this, e.g., by expanding http://newgtlds.icann.org/newgtlds.csv

That would be definitely useful, yes. We'd have to have a discussion
about how to use the information, but having it provided by ICANN would
be a great start.

Gerv

---

From: Jothan Frakes <[email-masked]>
Date: Tue, 3 Nov 2015 14:17:14 -0800

The default behavior of inclusion was created to accommodate the thundering
herd of new additions in a volunteer-only maintained list to keep it
lightweight with respect to level of effort - so that different
integrators, application developers, software libraries, etc, could have
some awareness of the TLD additions.

For the interest of not falling into the trap of where the definitions of
public / private seem to confuse things, the concept of public/private has
two connotations in this discussion.

First is placement within the Mozilla PSL - where there is a section
defining ICANN/IANA root down additions vs. self-identified strings that
have some cookie or other behavior that is TLD-esque where the operator
requested addition.

Second is where an entry is asserting an explicit non-public behavior (ie
!bloomberg)

@Francisco In the case of the second of these - there will be a need to
communicate with those registries to update their entries to suit their
specific desired behaviour with respect to cookies with the PSL.

Derivative users/integrators/security firms/developers that use the Mozilla
PSL for 'is that a valid TLD or not' logic will want names included, and
the overall Universal Acceptance benefit will remain regardless of if they
update their entry to be explicitly non-public.

Jothan Frakes
Tel: +1.206-355-0230