Re: [Cfrg] Request For Comments: OCB Internet-Draft

Steven Bellovin <smb@cs.columbia.edu> Tue, 19 July 2011 16:55 UTC

Return-Path: <smb@cs.columbia.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5A11E807E for <cfrg@ietfa.amsl.com>; Tue, 19 Jul 2011 09:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tybbFuOjgEts for <cfrg@ietfa.amsl.com>; Tue, 19 Jul 2011 09:55:24 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E411E8092 for <cfrg@irtf.org>; Tue, 19 Jul 2011 09:55:22 -0700 (PDT)
Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6JGtK6u022300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2011 12:55:20 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <B89E1A56-0533-4420-B6C6-8B8F81BEC2CE@krovetz.net>
Date: Tue, 19 Jul 2011 12:55:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <467FD947-3E53-443D-9975-902951F2A92E@cs.columbia.edu>
References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <FD9110CA-6C21-492D-9DE3-027C77A0A31F@krovetz.net> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> <B89E1A56-0533-4420-B6C6-8B8F81BEC2CE@krovetz.net>
To: Ted Krovetz <ted@krovetz.net>
X-Mailer: Apple Mail (2.1084)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 16:55:31 -0000

On Jul 15, 2011, at 12:45 06PM, Ted Krovetz wrote:

> 
>> If you know how "partial" that is, it would be useful for the draft.
> 
>> Ted, I think you can be rather more specific. 
> 
> 
> In my opinion the point of the nonce-reuse warning is to impress upon security engineers that catastrophe strikes if a nonce is reused during encryption, and so they should make nonce reuse impossible. If nonce reuse is impossible, then it is irrelevant how bad the damage is when nonces are reused.
> 
> RFC writers need to walk a fine line: RFCs are primarily a description of technology, but should include enough high-level context to inform against poor usage. I think the current warnings on nonce reuse do this, but if you can suggest a scenario where the current advice is being heeded and yet it is still useful to know how bad not heeding it would be, I'm open to adding some quantifications.
> 
> It may be worth adding a few paragraphs to the OCB paper describing and quantifying the damage, but I'm a bit reluctant to do so in the ID.

Also give a reference to a paper that gives more details.

Beyond that, both this issue and the bound on plaintext suggest that
this mode SHOULD NOT be used with manual key management.  You should
say that explicitly, perhaps with a reference to 4107.

Devices that lose dynamic state on reboot -- and in particular, lose
state about which nonces have been used -- are particularly vulnerable
here; this merits an extra warning, especially because many WEP
implementations have fallen victim to precisely this problem.  See
http://www.cs.berkeley.edu/~daw/papers/wep-mob01.pdf for details.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb