Re: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

"Lishan Li" <lilishan48@126.com> Wed, 29 July 2015 13:26 UTC

Return-Path: <lilishan48@126.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580091A0095 for <saag@ietfa.amsl.com>; Wed, 29 Jul 2015 06:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.36
X-Spam-Level:
X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJRtSWcB8-Ij for <saag@ietfa.amsl.com>; Wed, 29 Jul 2015 06:26:52 -0700 (PDT)
Received: from m15-57.126.com (m15-57.126.com [220.181.15.57]) by ietfa.amsl.com (Postfix) with ESMTP id A5DEE1A009B for <saag@ietf.org>; Wed, 29 Jul 2015 06:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=jTa61 KkwYGAP/FB16mG6r/fcsGTRJWFHGZMWvjlUS+0=; b=jsZU5Y8Q5PgFMtKAwvd6n 2jF0fZTu1e3h/aIa3F55Mkw0rncqJifQ15ulrKghSarkdFEgXqeGazx+2GRjGDHF YuyLI4gppWC58Y3etgrn14+5A1MTkJ8ngChRMo7tVfjw3A5Z/Do1EHrzrvnwSsD1 rjIFD+xaGDuWYeL9mgcjUw=
Received: from lilishan48$126.com ( [166.111.68.231, 176.34.62.243] ) by ajax-webmail-wmsvr57 (Coremail) ; Wed, 29 Jul 2015 21:25:28 +0800 (CST)
X-Originating-IP: [166.111.68.231, 176.34.62.243]
Date: Wed, 29 Jul 2015 21:25:28 +0800
From: Lishan Li <lilishan48@126.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150119(59087.7062) Copyright (c) 2002-2015 www.mailtech.cn 126com
In-Reply-To: <55B8A692.8080409@cs.tcd.ie>
References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <m2mvyfh1re.wl%randy@psg.com> <55B8A692.8080409@cs.tcd.ie>
X-CM-CTRLDATA: ICXlx2Zvb3Rlcl9odG09NDUyMjo4MQ==
Content-Type: multipart/alternative; boundary="----=_Part_232627_1251679550.1438176328745"
MIME-Version: 1.0
Message-ID: <3c4ad4b5.e9ed.14ed9fd3c2a.Coremail.lilishan48@126.com>
X-CM-TRANSID: OcqowAD3_4uF1LhVebASAA--.386W
X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbiEx9GwVWnfsOKEwABsc
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/AnmJFDyGVDjd0UGIB9hUnl4sBoQ>
Cc: cuiyong@tsinghua.edu.cn, Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] Fw:Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 13:26:54 -0000

Dear Stephen,


Thanks very much for your kind reply. 
I am considering whether the "Opportunistic Security" can be used. The opportunistic security make use of the encryption more broadly, authentication is optional. What do you think of the opportunistic security?


Best Regards,
Lishan
At 2015-07-29 18:10:26, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>
>Hi Randy,
>
>On 29/07/15 08:16, Randy Bush wrote:
>> this document, like the v4 dhc document, is all mechanism with no clear
>> statement of applicability.  neither document discusses key distribution
>> and management, the usual critical fulcrum of symmetric and asymetric
>> key-based mechanisms.  e.g. how does this work in a coffee shop?  and
>> the answer better not be tofu and leap of faith.
>
>I'm not keen on that kind of argument tbh where we say "show me your
>threat model and btw <this> better not be it." Can you Randy show me
>a good analysis of how different kinds of key management have which
>consequences for DHCP authentication and confidentiality? I don't
>believe I've seen that documented myself but I've not spent time
>looking specifically for it. In this case the authors are looking to
>us for help with getting that done, and I don't believe poking them
>like that is either useful or fair, sorry.
>
>As for TOFU, I do believe there may be a role for that in DHCP. There
>are cases where I informally start to use a sadly-open WiFi n/w and
>continue to use that for a few days or sporadically  (e.g. a friend's
>guest WiFi) and in such cases TOFU could provide some protection to
>some or maybe most of the population using such a network. (And even
>if my friend has WPA turned on, TOFU for DHCP might protect me from
>their clever kid who was in school when I arrived;-) It'd also not be
>reasonable to expect my friend to have asked permission from a CA
>before setting up the guest WiFi.
>
>And yes, there are enterprise cases where a local PKI could and maybe
>should be used instead. And yes one could argue that WiFi roaming
>arrangements and large franchises (e.g. starbucks) should find a way
>to put certs in place, but I'm not convinced that doing nothing until
>we reach that goal is reasonable. I am fairly convinced that always
>requiring use of a PKI would result in fairly ubiquitous lack of use.
>
>There may even be good arguments based on the nature of DHCP to the
>effect that I'll have to accept what TOFU would tell me to reject, but
>I also don't think I've seen that either. (When my putative friend
>above buys a new AP/DHCP-server that would be an issue for either TOFU
>or a PKI based answer, but perhaps not an insurmountable one in either
>case.)
>
>But we (the IETF) have a really bad history with DHCP security in that
>RFC 3118 [1] is perhaps the most commonly cited unused security RFC.
>One could I think claim it wins the security-BS contest for RFCs
>even shoving the evil bit down into 2nd place;-)
>
>Forty-seven (yes 47! [2]) other RFCs reference 3118 and that mostly
>means pretending to provide security via a reference that the authors
>fully know is BS. I have checked a number of times with such authors
>and 3118 seems comprehensively unused. I only ever got one .mil type
>person saying that they use it but he wasn't allowed say more. Nobody
>else has ever told me that they can or do use 3118. In fact, in most
>cases when I see a reference to 3118 as a security mechanism, I'll
>put on a DISCUSS ballot to call the authors out for the BS. And in
>many cases we find they just copied it from somewhere hoping it'd
>shut-up the security ADs;-)
>
>We can certainly improve on that sad state. And I would say that
>TOFU is a credible part of that until evidence or detailed argument
>to the contrary is produced, which you have yet to do.
>
>S.
>
>[1] https://tools.ietf.org/html/rfc3118
>[2] http://www.arkko.com/tools/allstats/citations-rfc3118.html
>
>
>> 
>> randy
>> 
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>