Re: [mif] Confirm call for adoption:draft-savolainen-mif-dns-server-selection

["Laganier, Julien" <[e-mail]>]

Hi Teemu,

> I'm not proposing we should defer the discussion of how to secure things, I'm
> saying we should not continue postpone progress of this work indefinitely
> waiting for discussion not taking place. E.g. during the past two months
> since Beijing I haven't seen any discussion on this list about this.

I don't think we're stalled: The period straight after an IETF meeting is
usually pretty quiet because everyone has to catch up with the other business
that wasn't taken care of during the meeting, and then there was the holiday
season. 

I also do not equate adoption as WG draft to progress. This work can progress
(a lot) without this specific draft being a WG draft by having the WG coming to
consensus on how to do this DHCP-based DNS server selection securely. This will
be a pre-requisite for publication anyway.

> We can discuss now for sure. 

Right, almost everybody should be back from holidays by now so let's do just
that...

> I would like to discuss the real severity of the attack vector in more depth.
> As far as I understood the concern was that the attacker selects a small
> subset of names (e.g. a single name) that it wants to give malicious DNS
> reply. As the subset of names being attacked would be small, it would be
> nontrivial to see attack is ongoing (or pending - most of the private names
> would resolve just fine). 

I am not sure the subset of names necessarily needs to be small. An attacker
could inject on the WLAN a DHCPv6 DNS selection option with .com or '.' (i.e. global)
as a prefix and declare itself as high preference and be able to divert all
of that traffic if the other interface has no DHCP server sending such a DNS selection
option.

> Now what if instead of this technology the node's implementation would be
> such that it always sends DNS queries to all DNS servers (at least one server
> per interface). In the usual case it could happen that it gets positive
> replies for questions (for *.corporate.com) sent over VPN, and NXDOMAIN when
> sent to DNS server of the visited WLAN (for example). Now couldn't the
> attacker on WLAN currently do it so that when the question to this specific
> server name comes, the visited network's DNS server would not reply NXDOMAIN,
> but positive answer instead? And as the visited networks DNS server is likely
> faster to reply than the server behind the VPN, similar redirection attack
> could be accomplished?

Right. Which is why if you have DNSSEC you'd wait for all answers from all 
interfaces first before returning to the application. Alternatively, if the
stack knew that one of the interface (WWAN) is more trusted than the other
(unauthenticated WLAN) it would wait for the answer from the more trusted
interface to return to the application.

> Or what if the attacker provides malicious RFC3646 search list option having
> "attacker.com" and reply NXDOMAIN until host asks for
> "targeted.server.corporate.com.attacker.com" and reply that with positive
> answer and hence take the traffic? (This is explained in section 6 of
> RFC3646). In that case even DNSSEC does not help.

RFC3646 specically says: 

   2. Resolve a name that contains any dots by first trying it as an
      FQDN and if that fails, with the names in the searchlist appended.

If there are indeed multiple alternative DNS servers on different network
interfaces providing multiple search lists, I would interpret the above
"resolve a name that contains any dots by first trying it as an FQDN on all
interfaces, and if that fails, with the names in the search list for the
respective interface appended." That seems to be to be the sensible way to
extend the 3646 provision to a multi-interfaced host.

> If the DNSSEC is the only concern you have, can't we just make a call to WG
> on who thinks it should be MUST and who thinks it should be SHOULD? But in
> presence of other DNS attacks, couldn't you separate DNSSEC requirement from
> individual tools, and just mandate DNSSEC implementation to cover all kinds
> of threats?

No offense but in the end, whatever the WG rough consensus is, if it does
introduce security vulnerabilities the draft is going to held on by the SEC AD. 

DNSSEC is not the only concern I have, I have actually outline another way to use that option in a less problematic manner than currently proposed: 

> > As to DNSSEC being a MUST or not in the tightly controlled environment you
> > evocate, I feel it might be OK to not require DNSSEC in those insofar an
> > implementation (S/W stack) can securely determine if it is in such an
> > environment.  

So maybe we ought to say that when receiving a DNS server selection option
from an untrusted network interface (e.g., unauthenticated WLAN, as opposed
to corporate WLAN or WWAN), the node MUST tries to resolve FQDN through DNS
servers on each of the interface to try to obtain DNSSEC protected DNS replies. 

This way DNSSEC isn't a MUST, but if it is deployed, the node is in a position
to avoid the DNS redirection attack that Ted originally outlined.

What do you think?

--julien