Subject: [mif] Adoption of draft-savolainen-mif-dns-server-selection as WG draft

From: Hui Deng <[email-masked]>
Date: Wed, 12 Jan 2011 23:29:27 +0800

Hello all

With the chair hat,

Based on the last call discussion in the mailing list, chairs observed that
one issue regarding to security
has been raised, but this won't be the critical one to prevent it from
becoming the WG draft.

MIF working group could continue to discuss how to improve it after it
become a WG draft based on the constructive contribution.

Chair could also issue the call for whether we need put the “Must" or
"Should" support DNSSEC to resolve the issue if needed.

Thank you all for the comment, please continue to help the editor to improve
the qulity of the document after WG draft submitted.

Best regards,

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 13 Jan 2011 14:02:44 -0800

Hello Hui,

Just a clarification from my side:

Hui Deng wroteL
> Hello all
>  
> With the chair hat,
> 
> Based on the last call discussion in the mailing list, chairs
> observed that one issue regarding to security has been raised, 
> but this won't be the critical one to prevent it from becoming
> the WG draft.
>  
> MIF working group could continue to discuss how to improve it
> after it become a WG draft based on the constructive contribution.
>  
> Chair could also issue the call for whether we need put the "Must"
> or "Should" support DNSSEC to resolve the issue if needed.

I don't think the issue is MUST or SHOULD support DNSSEC. I think the
issue is when you do not trust the interface or DHCP server from which 
your received the DHCP option, you MUST query all the DNS servers you have
and wait for answers before you're able to possibly validate DNSSEC. Then
you might want to prioritize the answers you have as per the DHCP option.
 
> Thank you all for the comment, please continue to help the editor
> to improve the qulity of the document after WG draft submitted.

I will review the last update from Teemu and provide feedback.

--julien

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Jan 2011 17:17:04 -0500

> you might want to prioritize the answers you have as per the DHCP option.

Apologies for having failed completely to follow up on any of this
stuff since Beijing; I plead dayjob interference.  Nevertheless, I
wanted to clarify something here.

If you are validating on the end point where you are doing the above,
then you can query any DNS server you like and you will be able to
detect if there is a DNS server lying to you.  That is, if you are
doing DNSSEC validation, then you will be able to detect which DNS
server is able to answer your query with a validatable reply.

In that sense, I think Julien is right in case you get a failure.  But
if you get a validatable response, I'm not so sure.

Now what about the case where you have a locally-scoped trust anchor
for a domain, example.com, and a root covering trust anchor as well?
On one interface for LAN-only-host.example.com you get a validatable
answer of NAME ERROR (3) and on the other interface you get a
validatable postive answer for that name, covered by the
locally-scoped trust anchor.  In this case, you have the ability to
know that you have a special trust anchor configured, and the good
people at ISC will tell you (well, one of them) that you ought to
prefer it or at least that you ought to be able to prefer it.  So that
seems like the right answer for this case (and it would be right to
look for an answer covered by that trust anchor and use it.

What about the case where LAN-only-host.example.com is actually signed
using the same chain of trust as any random "public Internet" name in
example.com?  I suspect the answer is going to have to be, "Don't do
that."  For if you get two responses, both of which validate, but they
have different answers in them, there is no reason whatever for you to
prefer one over the other.

This is rather unfortunate, as there actually isn't any mechanism in
DNS to be able to prefer one trust anchor over another.

A

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

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 07:15:56 +0000

Hi,

The host implementing this technology (in not-being-attacked case) would send the DNS query first over the interface where "LAN-only-host.example.com" would be positively validated with local trust anchor, as from that interface "example.com" suffix was learned on? It would be happy with that answer, and not even become aware of the negative validatable responses that would be received via other interfaces if asked. 

While being attacked (the other interface also advertising "example.com") the host might get negative but validatable reply, in which case it probably should try out other interfaces (especially if two interfaces are advertising "example.com")?

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Andrew Sullivan
> Sent: 14. tammikuuta 2011 00:17
> To: [email-masked]
> Subject: Re: [mif] Adoption of draft-savolainen-mif-dns-server-
> selection as WG draft
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Jan 2011 07:55:16 -0500

On Fri, Jan 14, 2011 at 07:15:56AM +0000, [email-masked] wrote:
> 
> The host implementing this technology (in not-being-attacked case)
> would send the DNS query first over the interface where
> "LAN-only-host.example.com" would be positively validated with local
> trust anchor, as from that interface "example.com" suffix was
> learned on?

How would it know?  I thought _ex hypothesi_ the problem was that a
host doesn't know which interface to use for which query, because you
can't rely on the DHCP hint because you have no way of trusting it.
So you just have to try blindly.

The host, however, could have a rule to prefer "closer" trust anchors
(i.e. to prefer to use the TA for example.com for validating it when
such a TA is configured).  So, having a TA for the root and a TA for
example.com, the host sends the query for LAN-only-host.example.com on
any interface, and as soon as the answer can be validated using the TA
for example.com, it knows that that interface is the one to use for
example.com.  But this won't work if the local view and the
Internet-wide view use the same trust anchor, because then the
example.com TA is not tied to the local view.  In that case, any
interface could be validated with the example.com TA and you would
lose the ability to make the inference.  (There remains open the
question of how example.com will validate when the host is not
attached to the locally-scoped network.  I think this is something
that DNS weenies still need to work out, because under some
implementations the suggestion I'm making is totally broken.)

> While being attacked (the other interface also advertising
> "example.com") the host might get negative but validatable reply, in
> which case it probably should try out other interfaces (especially
> if two interfaces are advertising "example.com")?

If the other interface advertises example.com, and the answer is
validatable, then all bets are off, I think.  But how is an attacker
going to produce a validatable response?  Is this just a DOS, in that
the attacker prevents you from using the local view of the DNS?

A

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

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 14:25:56 +0000

> From: ext Andrew Sullivan [mailto:[email-masked]]
> Sent: 14. tammikuuta 2011 14:55
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [email-masked]

No, the problem is that currently a node has no idea where to send the query so it has to send it out blindly (choose one interface randomly, like oftentimes currently, or stick on some preferred interface).

With the new option host can make more informed decision where to send the first query. 

> any interface, and as soon as the answer can be validated using the TA

"Any interface" is no go, as we do not want to send all DNS queries out of all interfaces or randomly pick interfaces. Fallbacks in failures is ok. 

I'm not a DNSSEC expert, so I really need assistance here. Do you suggest that if a host is configured with knowledge that example.com should be validated with TA (?) for example.com, and the response host receives is actually validated with TA for the root, the host would see that it should actually continue asking in hopes some other DNS server replies with something that validates with the desired trust anchor? (unless last DNS server was reached, in which case the reply should be passed to app for connection attempt?)

> implementations the suggestion I'm making is totally broken.)

Then you would use this option to make a pick. Of course it might happen that attacker lures host to go to extranet web site of your corporation rather than intranet web site, but the damage would not be too huge?
 
> the attacker prevents you from using the local view of the DNS?

I mean the server.example.com could have perfectly valid negative reply if example.com's authoritative name server is contacted from Internet, but would also have valid positive reply if authoritative name server is contacted from intranet. Hence if a host gets negative reply it does not mean DNS server of some other interface could not provide positive replies.

Best regards,

Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Jan 2011 09:50:31 -0500

On Fri, Jan 14, 2011 at 02:25:56PM +0000, [email-masked] wrote:
> 
> No, the problem is that currently a node has no idea where to send
> the query so it has to send it out blindly (choose one interface
> randomly, like oftentimes currently, or stick on some preferred
> interface).

Right, but my recollection of the objections both in the meetings and
on list is that this is just a walking invitation to attacks, because
there's no way to secure the connection.  (I'm not sure I completely
agree: this is already a problem with DHCP anyway.  But I guess this
makes possible a more focussed attack, which might be a problem.)
Therefore, if you're going to rely on DNSSEC to make this secure,
you're going to have to make some inferences from DNSSEC.

> With the new option host can make more informed decision where to

Only if you have some reason to trust the information, and we don't
currently have a way to do that on my reading.  (I have read the
draft, but only very quickly, so feel free to tell me to read more
closely.)

> "Any interface" is no go, as we do not want to send all DNS queries
> out of all interfaces or randomly pick interfaces. Fallbacks in
> failures is ok.
 
Right, I get that.  My point is that you don't actually have
trustworthy information yet, so you might have to do some probing
anyway.

> I'm not a DNSSEC expert, so I really need assistance here. Do you
> suggest that if a host is configured with knowledge that example.com
> should be validated with TA (?) for example.com, and the response
> host receives is actually validated with TA for the root, the host
> would see that it should actually continue asking in hopes some
> other DNS server replies with something that validates with the
> desired trust anchor? (unless last DNS server was reached, in which
> case the reply should be passed to app for connection attempt?)

Sorry for the jargon.  "TA" == "Trust Anchor".  That's the key you
have locally configured as something you can use to begin a validation
chain.  (I'm going to give this a gloss, and get several details
wrong, but it's close enough for our purposes.)  Normally, we'd expect
people to have a TA for the root, and do all validation from that
point.  But you can have some other TA as well.  For instance, you
could have a key just for example.com configured.  (Is that clear
enough?  If not, let me know and I'll expand more.)  There are
different interpretations of what to do in this case.

Suppose that you have a TA for example.com and a TA for the root.  You
get a response for host.example.com, and it validates by starting with
the root TA and proceeding down the chain to validate
host.example.com.  However, it does _not_ validate with the TA for
example.com.  What do you do?  Some people think you reject this as
invalid, because you have a "closer" TA (the one for example.com), and
you should "trust that more".  Others (I am among them) think you
should trust every path equivalently.  Still others think that this is
local policy, and the user needs to choose what kind of policy is in
place.

I think that the approach I am suggesting falls into this third
category, where the policy is, "If I have another network, then try it
until I get the one that validates with my example.com TA.  Otherwise,
trust the validation chain that works."  Or something like that.

The idea here is a kind of trust-but-verify.  If I got the clue from
DHCP that I ought to prefer interface-A for example.com, but my
locally-configured TA for example.com doesn't produce the results I
expect there, I am entitled to try other configured interfaces to see
whether my example.com TA works in those contexts.  If it does, then I
have (validatable) reason to discard the advice from DHCP and to
cleave instead to the interface that gave me validatable results using
my "closer" TA for example.com.

I should say that I am very uneasy with this, in that it's implicit
policy about "more trustworthy" keys, and I think that it grafts
something onto DNSSEC that isn't really in the design.  In this case,
however, I can see a practical value, so I think it might make some
sense.
 
> Then you would use this option to make a pick. Of course it might
> happen that attacker lures host to go to extranet web site of your
> corporation rather than intranet web site, but the damage would not
> be too huge?

It's likely at most a DOS, I agree, assuming that your DNSSEC
operations are working.

> I mean the server.example.com could have perfectly valid negative
> reply if example.com's authoritative name server is contacted from
> Internet, but would also have valid positive reply if authoritative
> name server is contacted from intranet. Hence if a host gets
> negative reply it does not mean DNS server of some other interface
> could not provide positive replies.

Right, so this is at most a denial of service.  I think the issue that
(Ted Lemon, I think?) was raising at the mic in Beijing was that,
without DNSSEC, this option makes it easier for someone to draw you
off to a fake DNS server and capture your traffic in a targetted way.
That does seem like a problem, though DHCP already sort of makes that
possible anyway.

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

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 15:17:39 +0000

> you're going to have to make some inferences from DNSSEC.

I included DNSSEC as people wanted it in:) Originally I thought we could do by using this option where feasible, e.g. with somehow trusted networks, and securing stuff e.g. with SSL/TLS.

For example, nowadays people use cellular, and then go to WLAN (one at a time). Happily doing so, but losing access to information possibly provided only via cellular network. I can use this option there e.g. so that host is simultaneously connected to cellular and WLAN and would send default queries to WLAN (faster - and as it would do if it were the only interface), but host would not lose visibility to information only available I cellular. The host would listen this option only from cellular interface, which it trusts.

In CPE case the CPE may listen for this only on its WAN VLANs, not from local WLAN. Hence it would have only trusted uplink interfaces.

> draft, but only very quickly, so feel free to tell me to read more

By deployment scenario.

On the dnsop list I spelled out this implementation alternative:
--
Anyway, we could have it also so that if the most preferred DNS server does not give positive validatable reply in half a second the node resends the query out on all interfaces to all DNS servers like a lightning storm. That would ensure the common case does not require DNS storming, but in case of trouble the user experience would remain good.
--

I will return to rest of your email later, have to go now:-)

Teemu

---

From: <[email-masked]>
Date: Mon, 17 Jan 2011 10:29:46 +0000

Andrew, I read the rest of your email now and I think I got the idea. I also think there's plenty of suggestions already to produce -01:) Will work on that.

Thank you,

Teemu 

> ext [email-masked]
> Sent: 14. tammikuuta 2011 17:18
> To: [email-masked]; [email-masked]
> I included DNSSEC as people wanted it in:) Originally I thought we
> could do by using this option where feasible, e.g. with somehow trusted
> networks, and securing stuff e.g. with SSL/TLS.
> 
> For example, nowadays people use cellular, and then go to WLAN (one at
> a time). Happily doing so, but losing access to information possibly
> provided only via cellular network. I can use this option there e.g. so
> that host is simultaneously connected to cellular and WLAN and would
> send default queries to WLAN (faster - and as it would do if it were
> the only interface), but host would not lose visibility to information
> only available I cellular. The host would listen this option only from
> cellular interface, which it trusts.
> 
> In CPE case the CPE may listen for this only on its WAN VLANs, not from
> local WLAN. Hence it would have only trusted uplink interfaces.
> 
> Anyway, we could have it also so that if the most preferred DNS server
> does not give positive validatable reply in half a second the node
> resends the query out on all interfaces to all DNS servers like a
> lightning storm. That would ensure the common case does not require DNS
> storming, but in case of trouble the user experience would remain good.
> --
>