Re: [Cfrg] Side inputs to signature systems, take 2
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 23 April 2016 20:19 UTC
Return-Path: <dkg@fifthhorseman.net>
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 34E3A12D558 for <cfrg@ietfa.amsl.com>; Sat, 23 Apr 2016 13:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 bZ_hC2aAEK3V for <cfrg@ietfa.amsl.com>; Sat, 23 Apr 2016 13:19:08 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 52EBA12D554 for <cfrg@irtf.org>; Sat, 23 Apr 2016 13:19:08 -0700 (PDT)
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 70749F991; Sat, 23 Apr 2016 16:19:07 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 5599C200E4; Sat, 23 Apr 2016 16:19:07 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "D. J. Bernstein" <djb@cr.yp.to>, cfrg@irtf.org
In-Reply-To: <20160423125954.25865.qmail@cr.yp.to>
References: <20160423125954.25865.qmail@cr.yp.to>
User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Sat, 23 Apr 2016 16:19:03 -0400
Message-ID: <87y484w020.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/-hf60lQJslm3zvh40QEo8k0xDS0>
Subject: Re: [Cfrg] Side inputs to signature systems, take 2
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2016 20:19:09 -0000
Hi Dan-- On Sat 2016-04-23 08:59:54 -0400, D. J. Bernstein wrote: > * The security analysis is almost entirely missing. It's easy to come > up with examples where the idea seems to work, but slightly more > thought shows many more examples where the idea fails, because it's > not directly aimed at the core cross-protocol issue. This seems to be saying that because domain separation by context labels doesn't solve all conceivable cross-protocol issues (i agree it does not) that we should not use it to address those issues that it does solve. Your PGP example is definitely correct. The PGP signature would not prevent collisions of multiple PGP messages with different interpretations. However, it *would* prevent a PGP signature from being replayed as a signature on a TLS certificate verify message from the same secret key (or a PKINIT message in krb5, etc) > * The syntax/layering/API analysis is entirely missing. In every case > where the idea is effective, the same benefit is also achieved by a > much more traditional fix that _doesn't_ change the signature API, > and this traditional fix is much easier from a systems perspective. i'm assuming that the "traditional fix" is just "incorporate a sane context-specific bytestring into the message being signed". And I agree, it would be great if people did that. But calling it a "traditional fix" implies that there is a tradition of doing the right thing here, and that's been inconsistent at best. Do you have a better suggestion of how to formalize this practice than giving protocol designers a place to put a distinct context? I'd be happy with other proposals that try to address the same issue. Thanks for the thoughtful discussion, --dkg
- [Cfrg] draft-irtf-cfrg-eddsa -- one final proposa… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Paterson, Kenny
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Salz, Rich
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Salz, Rich
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Russ Housley
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… David Jacobson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- [Cfrg] Side inputs to signature systems, take 2 D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems, take… Natanael
- Re: [Cfrg] Side inputs to signature systems, take… David Jacobson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] Side inputs to signature systems, take… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Bryan Ford
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Dang, Quynh (Fed)
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Bryan Ford
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Richard Outerbridge
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein