Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

Tony Putman <> Thu, 12 April 2018 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D14691271DF for <>; Thu, 12 Apr 2018 06:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2VOWIXYbKhSR for <>; Thu, 12 Apr 2018 06:23:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9F7E127333 for <>; Thu, 12 Apr 2018 06:23:51 -0700 (PDT)
X-IronPort-SPF: SKIP
X-IronPort-AV: E=McAfee;i="5900,7806,8859"; a="31512057"
X-IronPort-AV: E=Sophos; i="5.48,441,1517875200"; d="scan'208,217"; a="31512057"
Received: from unknown (HELO ([]) by with ESMTP; 12 Apr 2018 14:23:47 +0100
Received: from ( []) by (Service) with ESMTP id EDC0FFA10; Thu, 12 Apr 2018 11:43:05 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTP id CD564FA02; Thu, 12 Apr 2018 11:43:05 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 12 Apr 2018 14:23:46 +0100
Received: from ([fe80::3975:cbc9:490b:523a]) by ([]) with mapi id 14.03.0319.002; Thu, 12 Apr 2018 14:23:46 +0100
From: Tony Putman <>
To: Richard Barnes <>
CC: "<>" <>
Thread-Topic: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt
Thread-Index: AQHT0aURP8E25F81m0KNzl5SphxWl6P84Y0A
Date: Thu, 12 Apr 2018 13:23:44 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC1DBF718CUKMALMBOX01dyso_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt
X-Mailman-Version: 2.1.22
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: Thu, 12 Apr 2018 13:23:57 -0000

Hi Richard,

I work in the IoT space and am interested in handshakes that involve little computation but offer better protection than symmetric PSK in the event of server breach.

From: TLS [] On Behalf Of Richard Barnes
Sent: 11 April 2018 15:54

We would love to hear any feedback on the approach proposed here, and on whether other people here would be interested in working on a PAKE mechanism for TLS in this working group.

I was interested in this draft as it seemed to tick some boxes, and I offer some comments below. But in the end I don't think it offers what I'm looking for, so I can't offer to help with it in its current form.

My main comment is that I disagree with the assertion in section 3 that "w" is effectively a salted password hash. An attacker who obtains "w" can impersonate the client to the server, so it is equivalent to a password. The only advantage is that a server breach cannot be extended to other servers where the user uses the same password, but different salts are used. It seems to me that SPAKE2+ prevents this, so perhaps this should be used instead.

Secondly, SPAKE2 is fitted to the TLS 1.3 handshake by forcing the client to know the salt. This seems unreasonable to me unless there is also some mechanism to retrieve the salt from the server. Could the salt be a hash of client identity and server identity? (I suspect there is not enough entropy in this). But in any case I think this is an issue which must be addressed in the draft.

Why does the draft need to specify what the identity of the server is? It doesn't seem to be used.

Would it be helpful to send a list of SPAKE2Shares in ClientHello? For example, if the application layer protocol is being negotiated, would it be necessary to supply shares for multiple protocols? Alternatively, if the client and/or server support multiple pre-provisioned values (G, M, N, H), how would this be signalled/managed? And would there be associated security concerns?

It is worth noting explicitly somewhere that x and y should have the same ephemeral characteristics as are used by the key_share elements, and that if this is followed then forward secrecy is provided by SPAKE2.

IMHO "w" should not be used as the PSK input. If somebody gets hold of a derived key (e.g. early_exporter_master_secret) then the low entropy of "w" may allow it to be recovered. "K" provides all that's needed for key derivation.

The draft should recommend somewhere (security section?) that H should be suitable for password hashing (e.g. Argon2) and not a standard hash function. This is particularly true if my earlier suggestion to use SPAKE2+ is followed.


Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.