Subject: [Dbound] [[email-masked]: dbound meeting notes]

From: [email-masked]
Date: Tue, 29 Jul 2014 17:55:53 -0400

Hi all,

As some of you may recall (perhaps because you were there!), we had a
side meeting at IETF 90 in Toronto in order to try to get some
progress on this work.

Casey Deccio was kind enough to take notes and to send them to me to
be posted.  They match my memory, so I've included them unmolested
below.

To me, there were three main themes that came out.  First, there
appeared to be a very strong sense that we need the _location_ of a
policy had to be distinct from the statement of the policy itself.
There is a potential latency pitfall here, but it seems likely
manageable.  Another way to think of this is the distinction between
placing a boundary marker, and the boundary itself.

Second, there are three different use cases that all seem to need
somehow to be accommodated.  We must be able to express "responsible
for below me".  This mechanism, for instance, is what you need for
things like DMARC, where you're trying to assert (for instance) a mail
administrative domain.  We must be able to express ancestor-descendent
in/out relationships, so that (for instance) public suffixes can say
"I'm a delegation-centric name that accepts delegations from the
public".  This sort of approach is useful for reproducing the
_current_ behaviour of cookies.  Finally, there were fewer people but
more enthusiastic who want to be able to express full cross-tree
relationships, so that example.com and example.net can declare their
relationship.  This sort of scenario would help with both "IDN
variants" and also for large businesses with many different domains
(and cross-site scripting issues).

Third, it is plan that some use cases will tolerate slightly
less-accurate data in order to minimize latency or additional lookups
(e.g. the "cookies" case).  But contrast, some use cases require
maximal accuracy at the expense of latency (e.g. CAs trying to
determine correct boundaries when issuing certificates).

At the end of the meeting, four of us said we'd work on a problem
statement.  I've since been contacted by Marc Blanchet, who wasn't
able to make it but who apparently has some problem statement text
already written.  He said he'd send that to the I-D repository soon.

Best regards,

A

----- Forwarded message from "Deccio, Casey" <[email-masked]> -----

Date: Wed, 23 Jul 2014 22:11:59 +0000
From: "Deccio, Casey" <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Subject: dbound meeting notes

Hi Andrew,

Here is my assortment of notes.  They are really a (mostly) chronological documentation of comments, questions, and compilations that came up as we talked.  Hope that's useful.

Casey

---------

Background/Motivation (Andrew)
- complaint about public suffix list - entries being outdated
- policies being handled by one individual
- folks have attempted to do this within the DNS (e.g., finding zone cuts)

Other/Considerations
- desirable to handle mail policy using administrative boundaries
- SSL certificate names could be consolidated
- online/offline

Problems - addressed by current public suffix list or future design
(enumerated by group)
1. cookies
2. source domain/presented domain
3. wildcard certs
4. logging in certificate transparency
5. CA issuing problems (CN to auth agency mapping)
6. disjoint subtrees
7. common origin policy
8. DMARC policy covers subree
9. "extended TLD"
10. strict transport security
11. outsourcing

Comments/Questions from remaining discussion:

One idea for breaking this into two problems:
 - top-down policy
 - cross-tree policies

Idea for divide and conquer:
 - distinguish make markers vs. use markers
 - distinguish marker and boundary

Problem statement ideas:
- "Are these two names 'the same'" for some definition of "the same"?
- "If these names are equivalent, what is their canonical name?"
- "Fundamental problem is that security policies are being read off domain names"

Propose distinguishing between:
- How to find policy?
- How to communicate policy?

Solution characteristics to consider:
- online vs. offline
- strict hierarchy
- tree walking cost/benefit
- self-publish vs. third party
- retail vs. wholesale retrieval
- fresh vs. cache | consistency/coherence / speed vs. accuracy

Some PSL numbers read off (as of Sep 2013)
- Only 4 gTLDs and 8 ccTLDs have more than 50 entries in current PSL
- Most entries:
  - .jp 1750
  - .no 755
  - .museum 548
  - .it 278
- Mean number of entries with 2+ labels per gTLD: 43
- Median number of entries with 2+ labels per gTLD: 0

Should policy for an organization be made by other organizations (e.g., mozilla for dyn)?

Interest in establishing whether two domains map to the source domain

Do we need to cover getting referral content (e.g., images for apple.com served by akamai)

Comment:
Don't want to just go out and find out who is the authority, but who is the authority and what is the policy?

There are various common-authority-finding drafts and discussions going on in other working groups within the IETF
 - should we compile them?

Making a solution too wide could violate policies that currently exist (or are in discussion)

"Match" connotes a symmetric property, so use care with terminology
(counter point - wildcard "match")

Three primary components to administrative boundaries:
 - effective TLDs - public from top down (e.g., "co.uk")
 - domains below TLDs - public, followed by one or more private, followed by public (e.g., blogspot.com)
 - disjunct domains - associate two domains below TLD (e.g., foo.com with foo.net)

Team for defining problem statement:
 - Jeff, John, Casey, Andrew

----- End forwarded message -----

-- 
Andrew Sullivan
[email-masked]