IETF Logo Mail Archive

Re: [dhcwg] Moving SeDHCPv6 forward

Robert Elz <kre@munnari.OZ.AU> Fri, 20 March 2015 19:45 UTC

Return-Path: <kre@munnari.OZ.AU>
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 33B621B3025 for <dhcwg@ietfa.amsl.com>; Fri, 20 Mar 2015 12:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.344
X-Spam-Level:
X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 njpSRHyfhswq for <dhcwg@ietfa.amsl.com>; Fri, 20 Mar 2015 12:45:24 -0700 (PDT)
Received: from munnari.OZ.AU (unknown [IPv6:2001:3c8:9009:181::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472C31B301B for <dhcwg@ietf.org>; Fri, 20 Mar 2015 12:45:12 -0700 (PDT)
Received: from perseus.noi.kre.to (localhost [IPv6:::1]) by munnari.OZ.AU with ESMTP id t2KJfe0G007468; Sat, 21 Mar 2015 02:41:53 +0700 (ICT)
Received: from perseus.noi.kre.to (localhost [127.0.0.1]) by perseus.noi.kre.to (8.14.7/8.14.2) with ESMTP id t2KJfLdJ029923; Sat, 21 Mar 2015 02:41:26 +0700 (ICT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.5
From: Robert Elz <kre@munnari.OZ.AU>
To: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <F4EEEB91-CE04-40E4-9BB0-ED2C67F3347A@nominum.com>
References: <F4EEEB91-CE04-40E4-9BB0-ED2C67F3347A@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923B05E058@nkgeml512-mbx.china.huawei.com> <CAJE_bqdPR-VScm02mx=nRm_j5Bv6+TF6QR=+=YSSrvZ5c9zTJg@mail.gmail.com> <2134F8430051B64F815C691A62D9831832E1F673@XCH-BLV-504.nw.nos.boeing.com> <CAJE_bqeBFH5UBMgR--64ngri6h32d5x4Un0ze=d6=_s-oGj9yA@mail.gmail.com> <2134F8430051B64F815C691A62D9831832E203B5@XCH-BLV-504.nw.nos.boeing.com> <CAJE_bqfdYyyLgYBbUYNA=Wh9OTwdf377=bLReVfyhD1wQscX2g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832E20446@XCH-BLV-504.nw.nos.boeing.com> <10AFB9D0-E440-4243-9FBE-87E62CB6ED05@nominum.com> <2134F8430051B64F815C691A62D9831832E20478@XCH-BLV-504.nw.nos.boeing.com> <A24B47A0-7662-4E0C-B296-C9904013A5E1@nominum.com> <2134F8430051B64F815C691A62D9831832E21DA3@XCH-BLV-504.nw.nos.boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 21 Mar 2015 02:41:21 +0700
Message-ID: <15234.1426880481@perseus.noi.kre.to>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/qHiLZ96wfhioFht2lK_8EWqWMMs>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
Subject: Re: [dhcwg] Moving SeDHCPv6 forward
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: Fri, 20 Mar 2015 19:45:26 -0000

    Date:        Fri, 20 Mar 2015 14:29:05 -0400
    From:        Ted Lemon <Ted.Lemon@nominum.com>
    Message-ID:  <F4EEEB91-CE04-40E4-9BB0-ED2C67F3347A@nominum.com>

  | However, if you were planning to pre-share the key out of band anyway,
  | then there's no real advantage.

If you're using symmetric key shared keys, the server needs to store (online)
the keys of every possible legitimate client, in order to be able to verify
the things - meaning a logistic nightmare if the server is ever compromised
(or if it is even thought that it might have been - such as if it ever runs
any code that is discovered to have a vulnerability that might have been
exploited.)

On the other hand, certificate based authentication of clients doesn't
require the server to have (online) anything secret at all - clients need
their private key available, to sign the message, but just one of them.

Shared symmetric key for anything other than pure one to one uses is just
insane.

kre

v2.46.0 | Report a Bug | By Email | System Status