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

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2011 07:44:54 -0400

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
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 22:29:45 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Mar 2011 06:47:34 +0000

On Mar 29, 2011, at 12:29 AM, "[email-masked]" <[email-masked]> wrote:

I think there are four cases to consider here:

1. The server selection option is delivered across a secure, trusted channel.
2. The server selection option is not secure, but the client does DNSSEC validation.
3. The server selection option is not secure, the resolver does DNSSEC validation, and the client communicates with the resolver over a secure, trusted channel.
4. The DNS server IP address that is being recommended in the server selection option is known and trusted by the client; that is, the server selection option serves not to introduce the client to a new server, but rather to inform it that a server it has already been configured to trust is available to it for resolving certain domains.

I think any use of the server selection option that falls outside of these four cases should be excluded.   By excluding such cases, we eliminate the possibility that the server selection option can be used to initiate an attack that could not be initiated without it.

I think that trusting the cell provider connection is something that needs to be thought through carefully.   It may in fact be okay to do so.   But it depends on that channel being both secure and trusted, not just trusted.  In DHCP it's somewhat traditional to trust provider channels even though they aren't cryptographically secure, and we get away with this because they are in fact in secure locations, and the information we're trusting isn't that sensitive.   But those two rationalizations don't apply here--cell service is done by radio, and hence not in a secure location, and the information we propose to trust is in fact quite sensitive.

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 07:47:18 +0000

Then maybe something like (slight modification):
--
A node MAY request and accept OPTION_DNS_SERVER_SELECT in any of the following four cases. In other cases the node MUST NOT request or accept OPTION_DNS_SERVER_SELECT unless the node is specifically configured to do so.

1. The server selection option is delivered across a secure, trusted channel.
2. The server selection option is not secured, but the client on a node does DNSSEC validation.
3. The server selection option is not secured, the resolver does DNSSEC validation, and the client communicates with the resolver configured with server selection option over a secure, trusted channel.
4. The DNS server IP address that is being recommended in the server selection option is known and trusted by the client; that is, the server selection option serves not to introduce the client to a new server, but rather to inform it that a server it has already been configured to trust is available to it for resolving certain domains.
--
Where the case 4 could happen? When the trusted DNS server address is configured via some secure channel (e.g. administratively)?

The cellular interface (handset to first hop router) is AFAIK considered cryptographically secure. But anyhow, decision whether a channel is secure enough or not needs to be done case by case (e.g. by 3GPP(2), WiMAX Forum, BBF...).

Best regards,

	Teemu

> From: ext Ted Lemon [mailto:[email-masked]]
> Sent: 29. maaliskuuta 2011 08:48
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mif] Comments on draft-ietf-mif-dns-server-selection-01
> 
> 3. The server selection option is not secure, the resolver does DNSSEC
> validation, and the client communicates with the resolver over a
> secure, trusted channel.
> 4. The DNS server IP address that is being recommended in the server
> selection option is known and trusted by the client; that is, the
> server selection option serves not to introduce the client to a new
> server, but rather to inform it that a server it has already been
> configured to trust is available to it for resolving certain domains.
> 
> I think any use of the server selection option that falls outside of
> these four cases should be excluded.   By excluding such cases, we
> eliminate the possibility that the server selection option can be used
> to initiate an attack that could not be initiated without it.
> 
> I think that trusting the cell provider connection is something that
> needs to be thought through carefully.   It may in fact be okay to do
> so.   But it depends on that channel being both secure and trusted, not
> just trusted.  In DHCP it's somewhat traditional to trust provider
> channels even though they aren't cryptographically secure, and we get
> away with this because they are in fact in secure locations, and the
> information we're trusting isn't that sensitive.   But those two
> rationalizations don't apply here--cell service is done by radio, and
> hence not in a secure location, and the information we propose to trust
> is in fact quite sensitive.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Mar 2011 07:58:42 +0000

> Where the case 4 could happen? When the trusted DNS server address is configured via some secure channel (e.g. administratively)?

Yes, that's the case I had in mind.   It's probably worth defining the terms more clearly if there is agreement on the set of four requirements that I suggested, but I'm curious to know if Andrew and Peter think they make sense.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Mar 2011 08:50:26 -0400

> Yes, that's the case I had in mind.   It's probably worth defining the terms more clearly if there is agreement on the set of four requirements that I suggested, but I'm curious to know if Andrew a…

This was more or less what I had in mind with the many trust anchor
thing as well.

Essentially, the idea is that you use the DNSSEC trust anchor as
something similar to a VPN config: you need some prior configuration.
By having this extra Trust Anchor, you can have something that proves
your claims cryptographically.  But I'm still not sure whether that's
a use case we care about (it sounds like "no", to me).

A 

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.