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

<teemu.savolainen@nokia.com> Wed, 19 October 2011 17:58 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95B311E808A; Wed, 19 Oct 2011 10:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level:
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1eaLz0w0hve; Wed, 19 Oct 2011 10:58:59 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4B21F8C69; Wed, 19 Oct 2011 10:58:58 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9JHwV1b005940; Wed, 19 Oct 2011 20:58:55 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 20:58:40 +0300
Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 19 Oct 2011 19:58:40 +0200
Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.8]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 19:58:39 +0200
From: <teemu.savolainen@nokia.com>
To: <Ted.Lemon@nominum.com>
Thread-Topic: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document
Thread-Index: AQHMjnkxnryNBBR3OkaQECaRsTmFHJWD8JIg
Date: Wed, 19 Oct 2011 17:58:39 +0000
Message-ID: <916CE6CF87173740BC8A2CE4430969620378363C@008-AM1MPN1-037.mgdnok.nokia.com>
References: <COL118-W55403198A984BAAE44BA47B1F70@phx.gbl> <916CE6CF87173740BC8A2CE44309696203782D75@008-AM1MPN1-037.mgdnok.nokia.com> <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com>
In-Reply-To: <8B37A60F-0C55-4543-9ADB-2BA5A659B212@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvIhRytp+v9DPNmP/PIMrEEivHvrY5HV8ew2GaKnuV0phiGjieXUeaEr+yWBsV/pAsnh9Djy2SNxS7msksx6Z/OfCHRgEKpVgcONay+XxEo47aGlgukvaxzNwzA5o/3oGr9YnD+Nx0L9julOW/aDgk0kRd8q5+uGxXPDniEItQeQ733va8gB28zcacTy+Qv0p7MLPMeWb08YY03IqTg6hyvhN84V9KfPuJSEirxMClXnvaRX3+lusqXxPZI8ft7LsmccsCMBn7YMpmJQLMRmzFM=
x-originating-ip: [10.162.93.230]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02C9_01CC8EA1.DFA5DDD0"
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Oct 2011 17:58:40.0501 (UTC) FILETIME=[BBD6BA50:01CC8E88]
X-Nokia-AV: Clean
Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, pk@isoc.de, dhcwg@ietf.org, sa.morris7@googlemail.com, denghui02@hotmail.com
Subject: Re: [mif] [dhcwg] 2nd Last Call for MIF DNS server selection document
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2011 17:58:59 -0000

Ted, thank you for comments. 

Please feel free to propose text - I love constructive text proposals:-)
During following week would be nice, if possible, so that we can move
forward with the draft before the next IETF.

Now that you say it, we might state that not any VPN can be trusted by
default (but VPN is an example here), but e.g. a VPN Configuration Profile
could enable the setting for that particular VPN connection. If the trusted
VPN then **cks you up, then, well, trusted parties sometimes do that..

Best regards,

	Teemu

> -----Original Message-----
> From: ext Ted Lemon [mailto:Ted.Lemon@nominum.com]
> Sent: 19. lokakuuta 2011 19:07
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: Hui Deng; <mif@ietf.org>rg>; dnsext List; dnsop@ietf.org WG; DHC WG;
> sa.morris7@googlemail.com; pk@isoc.de
> Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection
> document
> 
> 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.