IETF Logo Mail Archive

[hybi] on applicability of AES

"Pat McManus @Mozilla" <mcmanus@ducksong.com> Tue, 11 January 2011 20:04 UTC

Return-Path: <mcmanus@ducksong.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0E03A6A9B for <hybi@core3.amsl.com>; Tue, 11 Jan 2011 12:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+BXM2OkBG1k for <hybi@core3.amsl.com>; Tue, 11 Jan 2011 12:04:39 -0800 (PST)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 236D73A6A77 for <hybi@ietf.org>; Tue, 11 Jan 2011 12:04:39 -0800 (PST)
Received: by linode.ducksong.com (Postfix, from userid 1000) id A5D4C10305; Tue, 11 Jan 2011 15:06:55 -0500 (EST)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id DA84810157 for <hybi@ietf.org>; Tue, 11 Jan 2011 15:06:50 -0500 (EST)
From: "Pat McManus @Mozilla" <mcmanus@ducksong.com>
To: hybi <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 11 Jan 2011 15:06:36 -0500
Message-ID: <1294776396.7650.829.camel@ds9.ducksong.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
Subject: [hybi] on applicability of AES
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2011 20:04:40 -0000

Hi all - awesome to see -04 out. Bedside reading tonight!

Mozilla sponsored some time for me to speak with a lawyer versed in
legal cryptography issues so I could ask him what he thought of AES as a
mask. He is a lawyer, but IANAL and I'm the one writing this email - so
please consider it just layman's background information.

Broadly speaking - in the USA normal use of AES in an exported
implementation would be subject to some registration rules that would
probably require legal help but are not that big of a deal, the details
of which depend on just how the implementation is done. As I understand
it, Open source implementations can more or less fall under a blanket
existing provision and don't need to go through explicit registration.

Also broadly speaking, and I don't have any more insight into this
sentence than what I am writing, his opinion was that a number of other
jurisdictions (UK, France, etc..) have similar regulations.

However, as pointed out here, the proposed masking use of AES is not a
normal crypto use. There is a no secret - all keys are transported in
plain text. The lawyer thought it was fair to consider whether or not
this use of the algorithm constituted cryptography - if it did not, then
the concerns about export regulations would not apply.

I hope to seek (and share) an official opinion on that question if AES
continues to be seriously considered, but the wheels of lawyers and the
government don't always churn as fast as we would like. As far as I'm
concerned, its an open question right now.

The discussion did not touch on non AES approaches.

My inclination at this point in time is that AES certainly carries some
baggage and while it might in the end be workable, we should avoid
exclusive use of it in favor of other workable schemes. I suppose we
could allow a negotiation between hmac-sha1 vs aes (with hmac-sha1 a
required LCD, as neither would be insecure) so implementors could trade
off between speed and regulations - but my gut says that's just
un-necessary complication of websockets.

-- 
http://www.getfirefox.com/

v2.23.0 | Report a Bug | By Email