IETF Logo Mail Archive

Re: [TLS] DHE key derivation

Hanno Böck <hanno@hboeck.de> Fri, 27 September 2013 16:59 UTC

Return-Path: <hanno@hboeck.de>
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 C894D21F93F3 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 09:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 2wfQPc8UpPtl for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 09:59:43 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 07F0511E814D for <tls@ietf.org>; Fri, 27 Sep 2013 09:59:37 -0700 (PDT)
Received: from localhost (91-66-72-107-dynip.superkabel.de [::ffff:91.66.72.107]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Sep 2013 18:59:36 +0200 id 00000000000000AA.000000005245B978.00007310
Date: Fri, 27 Sep 2013 18:59:31 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20130927185931.65d84034@hboeck.de>
In-Reply-To: <5245B550.70606@fifthhorseman.net>
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> <5245B550.70606@fifthhorseman.net>
X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="PGP-SHA256"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-29456-1380301176-0001-2"
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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:59:49 -0000

On Fri, 27 Sep 2013 12:41:52 -0400
Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

> 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)?

PFS should be default and non-PFS should be phased out. Problem solved.

(Another reference for this principle "one key one usage" is by the way
an old paper by Schneier with the title "Chosen Protocol attack":
https://www.schneier.com/paper-chosen-protocol.html
)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

v2.23.0 | Report a Bug | By Email