Re: [apps-discuss] draft-sullivan-domain-origin-assert-01.txt

[Andrew Sullivan <[e-mail]>]

Hi John,

Thanks for the comments.  A little further discussion inline.

On Sun, Aug 05, 2012 at 10:46:28PM -0400, John C Klensin wrote:

> we discussed briefly in Vancouver.  I think your explanation of
> the problem(s) and what you are trying to do is muddy,

Probably.  But I'm not sure you're right I'm trying to solve too many
problems at once.  See below.

> usage is, bluntly, a mess. In particular, the boundaries that
> are more specifically discussed in "zone cut" terms (delegation
> records and a requirement for an SOA record in the subsidiary
> domain (and zone) are widely known as "administrative
> boundaries".

Yeah.  I picked the current term as a kind of compromise -- some have
argued that these should be called "administrative domains", which is
surely worse.  But I like the "policy authority" suggestion, and will
try to do something with that.  

> More broadly, what you are trying to do here is to overlay an
> entirely different data structure --really a mesh-- on top of
> the strict hierarchy (with weak aliases) DNS structure. That
> mesh is multidimensional with the potential for arrangements by
> related domain names, by ports, and by scheme/protocol. 

Yes.  The problem here is that in the first draft on this topic I
didn't do this, and the response on the w3c web security list was that
without schemes and ports the entire idea was totally useless for
their purposes.  I am not sure how to reconcile that view with the
argument you make, which is that we're trying to make statements about
who's in charge of a name.  Perhaps, however, this is an example of
the "too many problems" you argue.

The difficulty I have is that the user base for this is really just
applications, web browsers prominently among them.  If their
developers say, "Without these other bits, this mechanism is no use to
me, and I won't implement it," that's a strong incentive for me to
want to include those other bits.  Maybe this means that one needs
more than one RR, but then we're into round trips that web browsers
also don't want to make.

> If very
> much of that is used, one could easily end up with a lot of
> these records at a given node, far exceeding the UDP limit and
> possibly causing other problems.  Worse, if a node makes an
> assertion about some set of other nodes and they make
> contradictory assertions (whether through malice, configuration
> error, or attempts at cleverness the spec doesn't anticipate),

Actually, I did think about both of these issues.  Section 7.1 points
out that you can exceed the UDP limits, although it doesn't talk about
the extent to which that is undesirable (frankly, I ran out of time to
discuss it at length).  The security consideration section notes that
you'd be an idiot to accept the results if both sides didn't agree,
but doesn't go further.  I'd be willing to make this stronger,
although there's at least one case of cookie use where I'm not sure
about whether it'd be ok not to check both sides.

> predicts, that port numbers of interest to a particular
> situation will occupy continuous ranges.  If they do not, even
> an attempt to make an assertion about port numbers could result
> in a lot of records.

Yes.  The draft says, "It does not, however, permit arbitrary
combinations of destination point and schemes without using more than
one RR."  I guess that could be clearer.

The reason that the port ranges and wildcard on the scheme are there
is exactly so that one can make these records port- and
scheme-insensitive.  I personally think that's the way it'd get used
most often anyway, but I'm willing to make the protocol a little
messier if it causes people who work on web browsers to think about it
some more.

> record that parallels the function and definition of the "DNS
> administrative authority origin" indication and information
> provided by the SOA record.  That model fits nicely with the DNS
> hierarchy (rather than trying to superimpose a new mesh on top
> of it) -- it just clearly defines the two types of boundaries
> separate from each other (which they are, of course).

This was the notion I originally had, yes.  (I didn't call it the SOPA
record, but one is tempted now that you've introduced the "Policy
Authority" term.)

> While aspects of the "variant" story are clearly in your mind

No, or anyway not exactly.  I think the variant story is just one
facet of exactly the same story over and over again: we need to make
explicit who has or does not have policy control over a given zone.
That's the issue with cookies, with cross-site problems, and with
"variants" too.  I don't think they're actually different problems,
which is why you think I'm trying to solve more than one problem at
the same time.

Best,

A

> (and I fear contributing to assorted fantasies of what the DNS
> can do to help with that without getting any real value in
> return), your one clear use case is the public suffix list and
> related cookie issues -- and those do not require port ranges,
> scheme lists, or identification of other domains with the same
> ownership -- it only requires clear identification of the
> administrative/control/ policy boundary.
> 
>    best,
>     john
> 
> 
> 
> 
> 
>  

-- 
Andrew Sullivan
[e-mail]