Re: [IPsec] everything old is new again
"Dan Harkins" <dharkins@lounge.org> Tue, 17 March 2015 02:49 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356211A914B for <ipsec@ietfa.amsl.com>; Mon, 16 Mar 2015 19:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 SHiFTjBolkag for <ipsec@ietfa.amsl.com>; Mon, 16 Mar 2015 19:48:58 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id AFD811A9131 for <ipsec@ietf.org>; Mon, 16 Mar 2015 19:48:58 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D29341FE01EA; Mon, 16 Mar 2015 19:48:57 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 Mar 2015 19:48:58 -0700 (PDT)
Message-ID: <f1dc6e6e90823ea446cd3b41233e816b.squirrel@www.trepanning.net>
In-Reply-To: <f697004c120a93a7f0fbcbd4d7979603.squirrel@www.trepanning.net>
References: <f697004c120a93a7f0fbcbd4d7979603.squirrel@www.trepanning.net>
Date: Mon, 16 Mar 2015 19:48:58 -0700
From: Dan Harkins <dharkins@lounge.org>
To: ipsec@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/ww4kkBLdlR8Y1sjY1MyqB2T2CVY>
Cc: draft-mglt-6lo-aes-implicit-iv.all@tools.ietf.org
Subject: Re: [IPsec] everything old is new again
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2015 02:49:00 -0000
And of course by, "does this implicit construction imply some kind of concatenationÂ…" I don't mean concatenation at all. I mean some sort of chopping off 32 bits. Sorry for the confusion. Dan. On Mon, March 16, 2015 4:37 pm, Dan Harkins wrote: > > Hello, > > I'm leaving too early to attend the ipsecme meeting at IETF 92 > but I notice that draft-mglt-6lo-aes-implicit-iv is on the > agenda as "other documents". > > The idea of using an implicit IV was brought up in the IPsec WG > back in 1997 and rejected (yes, this was just for CBC mode but > that's because CCM and GCM were not designed yet). Why is > this a good idea now? > > The "unpredictable"-ness of an IV for CBC mode addresses a > chosen plaintext attack that would otherwise reduce CBC mode > down to ECB mode (and enable a codebook attack). I _think_ > the draft addresses this because the IV ends up being secret > but that requires reading a bit into section 4. Namely, does one > take the "clear text payload" as plaintext and the "dedicated 16 > byte key" as the key for a single ECB-style encryption using AES? > It says there's a payload and a key and it says AES is used as > a PRP but no normative text to say exactly what to do to get > this IV. > > Also, if that is the way the IV is (secretly) generated then does > this propose using a 128-bit IV, the block length of AES, for GCM? > Most implementations use the default 96-bit IV so does this > implicit construction imply some kind of concatenation or does > it propose to use a 128-bit IV with GCM? SP 800-38D describes > an RBG-based IV construction, is that what this draft is doing? > > As an aside, the Security Considerations of this draft need work. > It says that IV generation "has been left to the implementation as > long as certain security requirements are met." What are they? Do > the different modes have different requirements? Are these > requirements met by this draft? If so, how? > > regards, > > Dan. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
- [IPsec] everything old is new again Dan Harkins
- Re: [IPsec] everything old is new again Dan Harkins