Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

Peter Gutmann <> Mon, 27 April 2015 06:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 944641B2E97 for <>; Sun, 26 Apr 2015 23:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.909
X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3plMpvB25CZs for <>; Sun, 26 Apr 2015 23:06:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A4DB1B2E96 for <>; Sun, 26 Apr 2015 23:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1430114769; x=1461650769; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L/5ft0CKnk3HFNTZSfdbGGEftx12rmh/DfddN7CDkB0=; b=bW1/So3ONTRZThwl56Ea//PxCva16CJhVrUHo6UOq70zTBfVASHIjB3Y cLecFEB/+g5f0xtPG7pY/3oeh6eBr9adzcJs+WldHnyqxRucEw8dSSzBv hqAiLcGOnm+TukfCzCMdvrp1ezLTV6GDD6lsDmCsJe8nr+Vzweuu3d/ON A=;
X-IronPort-AV: E=Sophos;i="5.11,655,1422874800"; d="scan'208,217";a="321458680"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 27 Apr 2015 18:06:05 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Mon, 27 Apr 2015 18:06:04 +1200
From: Peter Gutmann <>
To: Michael StJohns <>, Hugo Krawczyk <>
Thread-Topic: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
Thread-Index: AQHQfUY+XGJjjqO7sUqFueKgZO+tjZ1Yy7OAgAFFkQCAAdcsgIAC+fIAgAAW34CAAAi+gIABY96D
Date: Mon, 27 Apr 2015 06:06:02 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9A043F3CF02CD34C8E74AC1594475C73AB0084CAuxcn10tdc05UoAa_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2015 06:06:11 -0000

Michael StJohns <> writes:

>This isn't about TLS specifically, but about how an HSM makes sure an
>attacker can't extract TLS keys.

Stepping back a bit in order to actually see the woods here, why is this an
issue?  Anyone who's using hardware for performance reasons will offload
everything to an SSL terminator, almost everyone else who doesn't want to do
that will do the crypto on the host, those worried about private-key security
will store the server key in an HSM but not do the bulk crypto there because
doing it on the host is typically much faster, and even if you do use PKCS #11
to do your bulk crypto for TLS, any attacker who's in a position to extract
the session keys from an HSM via a PKCS #11 mechanism has to control the host
it's talking to, in which case they've got direct access to the plaintext

I realise that it's always possible to invent some scenario in which this is
an issue, but how much of a real-world impact does it actually have?  Bob
Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki list (and
it seemed his motivation for that was the need to be able to support it in
Mozilla's softoken implementation, for which he needed a defined PKCS #11
mechanism), and OASIS is just getting around to finalising the standard for
them now, seven years later.  This would seem to indicate that the actual
industry demand for this (not the hypothesised need but the real-world demand)
is a giant who-cares.

So as I've already said earlier in this discussion, create the best mechanism
that's a combination of good crypto design principles and ease of
implementation/deployment for existing implementations, and if someone
specifically wants to do it in an HSM they'll have to accept that they're the
odd corner case and deal with it.