Re: [mif] [dhcwg] 2nd Last Call for MIF DNS server selection document

Ted Lemon <> Wed, 19 October 2011 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03B7A21F8C4E; Wed, 19 Oct 2011 09:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.722
X-Spam-Status: No, score=-105.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f927hEfWBLbG; Wed, 19 Oct 2011 09:06:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5883621F8C4C; Wed, 19 Oct 2011 09:06:44 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP; Wed, 19 Oct 2011 09:06:44 PDT
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 561EF1B8319; Wed, 19 Oct 2011 09:06:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTPS id 47918190065; Wed, 19 Oct 2011 09:06:43 -0700 (PDT) (envelope-from
Received: from MBX-01.WIN.NOMINUM.COM ([]) by CAS-02.WIN.NOMINUM.COM ([]) with mapi id 14.01.0323.003; Wed, 19 Oct 2011 09:06:43 -0700
From: Ted Lemon <>
To: "<> " <>
Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document
Thread-Index: AQHMjipiaz0g2rqs70G2ngGlfgipv5WESzGA
Date: Wed, 19 Oct 2011 16:06:42 +0000
Message-ID: <>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "<>" <>, " WG" <>, dnsext List <>, "" <>, DHC WG <>, "" <>, Hui Deng <>
Subject: Re: [mif] [dhcwg] 2nd Last Call for MIF DNS server selection document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2011 16:06:46 -0000

The DHCP changes look good.  You can get multiple selection tuples in DHCPv4 if you want, but you seem to have decided its not important, which is fine by me.   Let me know if you want me to explain how to do that.

However, I reread the text on server selection, and it still has a serious and easily exploited security flaw.   In order for DNSSEC validation to save you from an attack, it has to be the case that you look the name up on every possible name server to see if any claim it's in a signed zone.   If one does, it has to be validated.   Right now it looks like if the "trusted" server doesn't sign the zone, the DNSSEC validation will never happen.   We dealt with this by trusting some networks more than others, and that eliminates a lot of the risk.

For example, in the case of a hotel net we're okay, because it will be less trusted than the 3G network.   The case I am most concerned with is when you VPN to a site that is not trusted: the default behavior will be to prefer the VPN link, because we presume it is more trustworthy.  A consultant who VPNs to multiple corporate sites could be spoofed here though, as could a user of a firewall bypass VPN.

Unfortunately, I don't know of a way to fix this that doesn't fire up both radios for every query.   Leaving this off by default is probably the best we can do, but it might be good to add more text to the security considerations section describing specific exploit scenarios.   The text in 10.1 and 10.2 doesn't address this particular attack vector.

I would propose adding a requirement that there be a mode, off by default, enabled by UI, in which the resolver just fires up both radios, battery be damned, but I am not sure anyone would use it, because it would be difficult to explain why and when they should.

So practically speaking, I am just proposing a tweak to the security considerations.   I will send text if you don't object.   Sorry for the late review.