IETF Logo Mail Archive

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

"Salz, Rich" <rsalz@akamai.com> Mon, 07 April 2014 19:08 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4637B1A07D2; Mon, 7 Apr 2014 12:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ZadV4h_jCEb4; Mon, 7 Apr 2014 12:08:14 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7519C1A0862; Mon, 7 Apr 2014 12:08:14 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 23969475C5; Mon, 7 Apr 2014 19:08:07 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5F1F9475C7; Mon, 7 Apr 2014 19:08:06 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 00A122035; Mon, 7 Apr 2014 19:08:05 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Mon, 7 Apr 2014 15:08:05 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Ben Laurie <ben@links.org>
Date: Mon, 07 Apr 2014 15:08:04 -0400
Thread-Topic: [saag] draft-iab-crypto-alg-agility-00
Thread-Index: Ac9Sbt3APIV6Sn3hQzGAAemoYAyUqgAAA0Pg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@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> <CAG5KPzxihe+k0x0njC+BANacmrrQyfU5RAY_EYcMYW2rx8DZfw@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <CAG5KPzzzmJhcPfs0cJuS3f8Lu_Rua9dj0XWaOZ0RQ0Mwyd+egw@mail.gmail.com>
In-Reply-To: <CAG5KPzzzmJhcPfs0cJuS3f8Lu_Rua9dj0XWaOZ0RQ0Mwyd+egw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/L-NC0E8Q8D76VyMGZU0-PQiX6Vc
Cc: "trans@ietf.org" <trans@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 19:08:19 -0000

So the concern is log servers that are going to reserve the right to "go rogue" by using weak crypto that could be subverted?  Or is there a different concern?
 
I believe this can be addressed by leaving the data formats future-proof, but mandating the crypto in the RFC. For example, put a hash identifier (OID, TLS id, whatever) in the hash entry, but the RFC says "MUST use SHA-256."  To make it even stronger, you could set up an IANA registry. Being pragmatic, nobody's going to implement anything other than what Chrome supports, at least at first. And by making log data self-identifying, you can (quietly) perform experiments on new crypto types.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

v2.23.0 | Report a Bug | By Email