Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

Ted Lemon <Ted.Lemon@nominum.com> Mon, 13 February 2012 21:21 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30B21E8038; Mon, 13 Feb 2012 13:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.523
X-Spam-Level:
X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 AXwrF-XhHwXh; Mon, 13 Feb 2012 13:21:33 -0800 (PST)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 741C021E802A; Mon, 13 Feb 2012 13:21:33 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTzl+3AWBTH+ZBzbE8y6S311ALaG6upRI@postini.com; Mon, 13 Feb 2012 13:21:33 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6C0861B81E4; Mon, 13 Feb 2012 13:21:32 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 63025190052; Mon, 13 Feb 2012 13:21:32 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Mon, 13 Feb 2012 13:21:32 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
Thread-Index: AQHM5SWUy8EqSdK3C0aOhQFr8l21aJY2slwAgAG8tQCAA3NmAIAABEKA
Date: Mon, 13 Feb 2012 21:21:32 +0000
Message-ID: <EADDD673-E8FF-4579-9996-1E15C8933A70@nominum.com>
References: <A57C4722-5E13-451E-ACB4-CAA8064FA68B@nostrum.com> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB2@GRFMBX704BA020.griffon.local> <CEA6CD8F-7DCD-448C-8C31-EC64FD9902A3@nominum.com> <F184B794-3D1D-4A5A-860E-288DF2600DD6@nostrum.com>
In-Reply-To: <F184B794-3D1D-4A5A-860E-288DF2600DD6@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_EADDD673E8FF457999961E15C8933A70nominumcom_"
MIME-Version: 1.0
Cc: The IETF <ietf@ietf.org>, "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "draft-ietf-dhc-forcerenew-nonce.all@tools.ietf.org" <draft-ietf-dhc-forcerenew-nonce.all@tools.ietf.org>, Ullio Mario <mario.ullio@telecomitalia.it>, "Henderickx, Wim \(Wim\)" <wim.henderickx@alcatel-lucent.com>, Maglione Roberta <roberta.maglione@telecomitalia.it>
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 21:21:34 -0000

On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC?

Hm, I thought about that a bit more after I wrote my response.   The HMAC allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW.   I don't think this adds any value from a security perspective, actually, even though it feels more comfortable.   I suspect it was put in in the original version simply because of that—why send a secret over the wire when you don't have to?   However, the original motivation for using the mechanism from RFC3315 was to avoid defining a new mechanism for a legacy protocol.   If we do need to change it, it's going to require a major rework of the document, and a lot of delay, so if it causes no harm, I think that's not worth doing.

I too would like to see the text I proposed added to the security considerations, so that we can be clear about what is being accomplished with this draft.