[mif] Comments on draft-ietf-mif-dns-server-selection-01

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I have read draft-ietf-mif-dns-server-selection-01.  I have some
comments.  Apologies for having failed to comment sooner.

The fundamental issue here is split horizon DNS.  This has two
different cases:

    1.  There are subsets of the name space that are resolvable from
    inside one network, but are not really globally resolvable.  On
    the "inside network" of a corporate LAN, for instance,
    printer1.example.com might be a useful hostname, but not one that
    could be resolved from the public authoritative servers for
    example.com.  On the public Internet, a query for
    printer1.example.com gets a Name Error response.

    2.  There are subsets of the name space that are globally
    resolvable, but that resolve differently depending one's
    network-topologic location.  The obvious example is
    www.example.com, which is the public web server for everyone in
    the world but which provides a different experience inside the
    corporate network (and indeed, which may be a completely different
    host).  

The reason I want to distinguish these is that, if one contacts the
wrong name server in case (1), it is only a denial of service; whereas
if one contacts the wrong name server in case (2), one goes to the
wrong place.  (1) can be easily detected by even the most naïve user,
whereas (2) might not be obvious.

While I think the VPN case is important, whether one happens to be
using a VPN or happens instead to be attached to more than one network
is sort of irrelevant to the matter: the VPN is a compelling use-case,
but the basic issue is just a split horizon.

I find some appeal in its use of a dhcp option to say, "I know about
[name spaces]."  As the draft stands, it is not exactly clear how to
extablish trust in this announcement, however.  This seems like a new
way for wireless hotpots to hijack my corporate lookups, so it bugs
me.  The draft on several occasions talks about a connection being
"considered secure", and I am gravely worried that unpacking that
meaning of "secure" is still to be done.

I think what could help is a clearer account of exactly what assurance
one can get from DNSSEC and how it may help, what assurance one can
get from configuration that is somehow externally assured (or even
just a remark that "how to determine trust in these cases is..."
[undefined|beyond scope|defined in {ref}]).

Here are some ways that you can do useful validation with DNSSEC.  To
me, this isn't clear in the draft as it is.  I'm not sure where to put
any of the following.

    Because DNSSEC provides cryptographic assurance of the integrity
    of DNS data, data that can be validated under DNSSEC is
    necessarily to be preferred over data that cannot be.  It follows
    that, if validation is not performed by the host making the
    decision about whether to trust the DNS data from a given
    interface, it cannot make a decision to prefer data from any
    interface with any great assurance: any response could be forged,
    and there is no way to detect it without DNSSEC.  



    In validatiing DNS answers with DNSSEC, a validator might order
    the list of trust anchors it uses to start validation chains, in
    terms of the host's preferences for those trust anchors.  A host
    could use this ability in order to select among alternative
    DNS results from different interfaces.  Suppose that a host has
    a trust anchor for the public DNS root, and also has a
    special-purpose trust anchor for example.com.  An answer is
    received on interface i1 for www.example.com, and the validation
    for that succeeds by using the public trust anchor.  Also, an
    answer is received on interface i2 for www.example.com, and the
    validation for that succeeds by using the trust anchor for
    example.com.  In this case, the host has evidence for relying on
    i2 for answers in the example.com zone.

I hope this is helpful

Best regards,

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.