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

From: John C Klensin <[email-masked]>
Date: Sun, 05 Aug 2012 22:46:28 -0400

Andrew,

I find this document fairly troubling, largely for the reasons
we discussed briefly in Vancouver.  I think your explanation of
the problem(s) and what you are trying to do is muddy, in part
because it seems to me that you are trying to solve too many
problems, some of them simply incompatible with the architecture
of the DNS.  To make things worse, the terminology is confusing,
perhaps because of the old problem that existing DNS terminology
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".  Your using that term, or even "administrative
realm" is an invitation to confusion and trouble, especially in
the absence of text that explicitly repudiates the earlier usage.

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.  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),
one could end up with a rather interesting mess.  I note in that
regard that, in the general case, nothing ensures, or even
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.

Putting aside the nomenclature issues with "administrative"
mentioned above for a moment, I suggest that one could get a
good 90% solution simply by defining a "policy authority origin"
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).

The missing 10% includes protocol-sensitive machinery
("schemes"), and port-sensitive machinery, both of which we've
tended to avoid in the DNS architecture unless the relevant
records really are bound to particular protocols.  It also
includes the ability for one node to make assertions about a
node elsewhere in the hierarchy without necessarily having
permission from the target node -- effectively repeating and
extending the problem we have with aliases (reinforced by the
limitations of DNSSEC in those cases).  I think (although I'm
not yet ready to try to convince others), that it puts us
further into the situation of trying to build a trust model on
the integrity of registrars -- in today's environment, that
isn't a risk factor but a certain problem.

I can suggest some specific language to clarify the current
draft if that were appropriate, but I think you should consider
whether a much simpler model with provide most of the
functionality you are looking for with considerably less
potential complexity and the introduction of new risks.
Conversely, I think you should be required to really justify the
importance of port ranges, lists of URI schemes, and lists of
names that share owners rather than just putting those
capabilities in because (maybe) we know how.  

While aspects of the "variant" story are clearly in your mind
(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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Aug 2012 10:22:55 -0400

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:

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

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

> 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

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.

> an attempt to make an assertion about port numbers could result

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.

> 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

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Aug 2012 13:29:09 -0400

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

>...

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

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

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

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

> 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