IETF Logo Mail Archive

Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

Ralph Droms <rdroms.ietf@gmail.com> Sat, 31 May 2014 01:10 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920D21A06CB for <dhcwg@ietfa.amsl.com>; Fri, 30 May 2014 18:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 Syu2He4_uihH for <dhcwg@ietfa.amsl.com>; Fri, 30 May 2014 18:10:23 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85741A06D1 for <dhcwg@ietf.org>; Fri, 30 May 2014 18:10:05 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id q108so7563927qgd.27 for <dhcwg@ietf.org>; Fri, 30 May 2014 18:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ja+q8BGigTi0ESB/7uKbZpSeZ9Wxgfbqdl8Y/ayComM=; b=b2x49gPNVbaPhs+azqBgZkMx14blt/iabzTaAo8k3aal5W4ZWlTOixrIqdo0IRDmWs 1x/4vXN2D5Uon3jznMTadbt8KmYgi0LcG8aB3hcTaiLSuABsgT4WR74xR5X1G/vC9VNb LrWQBTmrPL4T398pPclCk2YkgnoV3R4LIv95cbrzsvtre5nvVk+EhxvlycIm5QB0pwpu LLTrb8coRqfsJXNIF5X8lYBTy/5D2DGokyXLE1O6HQDNJPBvm/HxNN3h32Z/XYzRDAm2 ZBXrUmVmrWYzSlRsdhKBGeEeYP8iq09oCmas8l0JwBNPyBUURS/MrnVxi9Yx7gf+cMoB 0ARg==
X-Received: by 10.229.234.67 with SMTP id kb3mr26720120qcb.6.1401498600875; Fri, 30 May 2014 18:10:00 -0700 (PDT)
Received: from che-vpn-cluster-2-271.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id s60sm3508740qga.30.2014.05.30.18.09.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 18:09:57 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <9EC3E851-483F-49CA-8C76-8D3149E4A230@nominum.com>
Date: Fri, 30 May 2014 21:09:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1A3F542-E891-4B5D-961A-ED86E9234B03@gmail.com>
References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <F079574B-FF8A-4C8B-B562-0E0F8D4DC47F@gmail.com> <9EC3E851-483F-49CA-8C76-8D3149E4A230@nominum.com>
To: Lemon Ted <ted.lemon@nominum.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/DK7aKZ8boeuuporBvRkZ255zvjM
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 01:10:25 -0000

On May 30, 2014, at 8:58 PM 5/30/14, Ted Lemon <ted.lemon@nominum.com> wrote:

> On May 30, 2014, at 8:57 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>> In my opinion, there is a need in the document for an applicability statement that gives guidance about what this mechanism provides and in what situations it is useful.  I have come to this opinion because a precise understanding of exactly what the protocol will provide will be important to those considering its deployment.
> 
> Isn't it applicable in any case where you want to authenticate the other endpoint that you are communicating with?   Are there use cases where you want that but this mechanism wouldn't be the right mechanism?
> 
> 
My concern is that the RFC should be clear that authenticating the other endpoint isn't always enough, or can't be used in some situations.  Authenticating messages from a malicious server doesn't do much good.  I don't see how this mechanism could be used in an open network situation like at your local coffee chain shop.

- Ralph

v2.23.0 | Report a Bug | By Email