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

[<[e-mail]>]

Hi Andrew,

Of those two the case 1 is something we have targeted with this document and the case 2 is something I think is very hard to tackle with a protocol. As we've seen, the case 2 might even lead user to the same service, but one that provides more or less different service depending on perceived location of the user...

Hence I would scope solution only to the case 1.

I looked at RFC4035 that says:
--
   A resolver MUST disregard the meaning of the CD and AD bits in a
   response unless the response was obtained by using a secure channel
   or the resolver was specifically configured to regard the message
   header bits without using a secure channel.
--

So maybe something like this would cover the trust issue:
--
   A node MUST not request or accept OPTION_DNS_SERVER_SELECT 
   unless the option was received by using a secure channel
   or the node was specifically configured to regard the option
   without using a secure channel.
--
Unless it limits the applicability too much? Anyhow, for the use cases we target that probably would suit, as we could consider cellular interfaces as secure channel.

The DNSSEC texts are good, thank you. The first part will find place in the document, for the second let's decide if we want trust anchor dependent response selection included or not.

Best regards,

	Teemu

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> ext Andrew Sullivan
> Sent: 28. maaliskuuta 2011 13:45
> To: [e-mail]
> Subject: [mif] Comments on draft-ietf-mif-dns-server-selection-01
> 
> 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.
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif