IETF Logo Mail Archive

Re: [saag] draft-iab-crypto-alg-agility-00

Ben Laurie <ben@links.org> Mon, 07 April 2014 09:25 UTC

Return-Path: <benlaurie@gmail.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 2DD461A06A3 for <saag@ietfa.amsl.com>; Mon, 7 Apr 2014 02:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level:
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 6_xE97fRx8a7 for <saag@ietfa.amsl.com>; Mon, 7 Apr 2014 02:25:43 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id A34DA1A06AD for <saag@ietf.org>; Mon, 7 Apr 2014 02:25:42 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id q108so5831279qgd.24 for <saag@ietf.org>; Mon, 07 Apr 2014 02:25:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Yy/t9p2vnWdWBO6Eav/xxqBZeUpthVyfQs96KdEIx/0=; b=xr2WutN1fmUxRaoNuL1VIAtHFQJMHyse/hB/Kci+/1tCJdJt8vUuThuaiKRFeaDAdi AHFoz5XOG4jUi7f6gpAZv/oYtNcqpJ5uQPesSB/rNRIMLzozDY2yt/dtVAm5LIBYGqLX QxlKC+2P6+sTbTJM7HZ6cai6/vYz7xYfG64wCXBCNSp49s4CwdbNaD4F5czpF1QohvFa Q6iWW3Fiv1DOZxc1GIARrFhFrxv18Vw0Uu0smih78Su7NkEDMObbsyZ8LRqUN85hPKtd +n7HoVmClLUY+bsoJYgfSike9btvXI/GreQmO2ZC14IH4R1mmiY6oj2F1N67F5REbEGV 9VtA==
MIME-Version: 1.0
X-Received: by 10.140.28.70 with SMTP id 64mr30532507qgy.36.1396862736929; Mon, 07 Apr 2014 02:25:36 -0700 (PDT)
Sender: benlaurie@gmail.com
Received: by 10.96.157.137 with HTTP; Mon, 7 Apr 2014 02:25:36 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com>
References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <CAG5KPzzqSQ++YpQcnYesecL0GQ0+J0ieMXBrNk6txMAC58xEQQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com>
Date: Mon, 7 Apr 2014 10:25:36 +0100
X-Google-Sender-Auth: 4IxK4iWe1_wI-2ywUPZZ5F8o7lc
Message-ID: <CAG5KPzxihe+k0x0njC+BANacmrrQyfU5RAY_EYcMYW2rx8DZfw@mail.gmail.com>
From: Ben Laurie <ben@links.org>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bxOU09ZVTMok-zSmW8_8jkzDAHo
Cc: S Moonesamy <sm+ietf@elandsys.com>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] draft-iab-crypto-alg-agility-00
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: <http://www.ietf.org/mail-archive/web/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: Mon, 07 Apr 2014 09:25:48 -0000

On 6 April 2014 22:54, Salz, Rich <rsalz@akamai.com> wrote:
> I know what the text says.  But there are no protocol operations, really, it's just HTTP/JSON, right?
>
> Having said that, I think the agility document should say "protocols and data formats."
>
> I was arguing (with Google folks, mainly) for crypto identifies in the CT data structures before the WG was convened. And I still think that CT should be brought in line with the letter and spirit of the agility document:  identify the mechanisms used, in the data types. If interop is a concern, make the current set be MUST and say SHOULD NOT implement anything else.
>
> CT should not be a special case exemption from the agility spec.

I think it should, and here's why: normally you want agility so
endpoints can change their crypto in an orderly way, so as to phase
out weak algorithms. In CT the endpoint is the enemy: you don't want
it to be able to choose algorithms that suit it.

v2.8.7 | Report a Bug | By Email