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

[John C Klensin <[e-mail]>]

--On Monday, August 06, 2012 10:22 -0400 Andrew Sullivan
<[e-mail]> wrote:

> Hi John,
> 
> Thanks for the comments.  A little further discussion inline.
>...

(Material where we seem to agree, at least until the next draft,
elided)

>...
>> 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.

Well, I don't quite know what their purpose is.  Certainly I
haven't seen anything that requires distinctions by schemes and
ports in any of the I-Ds on, if you will forgive me, cookie
cutting.  I might have missed one, of course.    But I note
that, if you make distinctions that allow different
ownership/administration for different ports or protocols, it
gets us pretty far into the territory of some non-DNS model,
perhaps even DNS 2.  The DNS is designed around names that are
associated with particular hosts (possibly virtual ones) or, in
the case of SRV and maybe NAPTR, protocols.  Historically, we've
dealt with the problem of a different host serving multiple
functions that have to be dealt with differently by assigning
different names.   One might, for example, have www.example.com,
smtp.example.com, imap.example.com, etc., even if they pointed
to the same interface on the same host (see RFC 2142 for a
discussion of an instance of that approach).

With the DNS, one owns names, not name/port, name/uri-scheme,
etc., objects.  Ownership of names for services implies that one
would need to attach these records to nodes that are otherwise
associated with, e.g., service location (e.g., SRV) records and
service definition (e.g., NAPTR or the sometimes-proposed URI)
records.  If that is what you want to do, the document isn't
clear about it and its implications.  Or you may have a
different model entirely, in which case I'll plead that the
document explain it.]

> 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.

While I see your point, I think there is risk associated with
changing the DNS architecture from an administrative hierarchy
(in the traditional sense, where entities can take
responsibility for, and manage, their own name spaces and
allocations rather than obtaining them from a superior entity)
to a mesh or even to a flat structure.  The decision in the
early 1980s to design things that way was a conscious choice
(see RFC 819 for some illustrative discussion).  If the intent
had been to develop a new flat structure -- replacing the flat
host table with a database with better scaling properties-- many
decisions would have been made differently.  Given how things
have evolved, we might have been better off.  For example, as we
have discussed several times, the host table supported
operations on aliases that the DNS does not.

So I'm nervous about trying to put records into the DNS whose
purpose is to change the architecture, fundamental relationships
among names, and nature of the names themselves (into bindings
and authority relationships to protocols and URI schemes, not
network objects like hosts).  If we need those sorts of
properties, I think it is probably time for DNSng, not patches
like this that work in some ways but that produce new potential
fir surprises and perhaps even vulnerabilities as side-effects.

If we want to stick with the present DNS and the web needs
something different, it may be time to insert a real overlay
database that is more harmonious with the URI model (including
better provisions for i18n), rather than trying to tweak the DNS
in that direction.

>> 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.

Yes, I noticed that text.   If we can't get rid of at least most
of the problem, I think you have to address those issues.  In
particular, I think the implicit requirement to access "both
sides" and compare the information needs to be brought out and
discussed, if only because it runs counter to some possible
performance requirements and, if, e.g., different port ranges or
different schemens for a given node can have different owners,
some interesting comparison issues.
 
>...
> 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.

At least so far, I'm not convinced that it is a better solution
than insisting of different names (DNS nodes) when different
ownership properties are required.
 
>> 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.)

I guess my hypothesis is that, if one needs much greater
functionality and distinctions than that, it is either time to
go to a name-per-function architecture (mostly a collection of
administrative decisions) or to [re]start either the DNSng
conversation or the "overlay database with different structural
and search properties" ones.

>> 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.

Yes and no.  The thing that makes the variant problem different
is that, in principle, it ultimately involves yet another sort
of authority relationship.  To use a familiar example that ICANN
wants to avoid (but that I don't believe they will be able to
hold the line on if general variants are permitted), suppose
AngloAmerNames goes out and obtains a bunch of spelling
variants: color and colour, harbour and harbor, center and
centre, etc.  Now, while all would have the same owner, at least
initially, "color" has a lot less to do with "centre" than it
does with "colour".  Moreover, unless ICANN or some other
superior registry authority tries to legislate rule they
probably cannot enforce, AngloAmerNames might easily arrange to
have "harbor" and "harbour" delegated to separate parties even
while insisting that the two domains be maintained in a
coordinated way.  That might actually cause policy authority
from a variant standpoint to diverge from policy authority from
an ownership/control one, leading one to need either an even
more complex RRtype or an additional sort of record.

    john