Re: [TLS] DHE key derivation

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 27 September 2013 16:42 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37EF21E8100 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 09:42:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHwScZZNr+rL for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 09:41:58 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BDB2621E809F for <tls@ietf.org>; Fri, 27 Sep 2013 09:41:58 -0700 (PDT)
Received: from [192.168.13.175] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1029FF983 for <tls@ietf.org>; Fri, 27 Sep 2013 12:41:54 -0400 (EDT)
Message-ID: <5245B550.70606@fifthhorseman.net>
Date: Fri, 27 Sep 2013 12:41:52 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: TLS Mailing List <tls@ietf.org>
References: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com> <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com> <op.w30xbev03dfyax@killashandra.invalid.invalid> <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com> <5245A292.1060909@pobox.com> <5245A6FA.8080607@fifthhorseman.net> <5245AFEB.7040202@pobox.com>
In-Reply-To: <5245AFEB.7040202@pobox.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="----enig2XSIKWQMKIDTSIGRSKSQC"
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "tls@ietf.org" <tls@ietf.org>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 16:42:04 -0000

On 09/27/2013 12:18 PM, Michael D'Errico wrote:
> The recommendation is if you want to reuse N for both operations, then
> choose different public exponents such as e=3 for signing and e=5 for
> encryption.  I'm pretty sure you can't do this using the same X.509
> certificate.

Right, you can't do that with the same X.509 certificate because the
subjectPublicKeyInfo (SPKI) data for RSA keys includes both N and E, and
is covered by the certificate's signature.

So: is this common practice something we should be pushing back on (e.g.
encouraging implementors to provide mechanisms to use separate keys and
certs for the PFS suites, and administrators to adopt those mechanisms)?

	--dkg