Re: [TLS] draft-wood-tls-external-psk-importer-00

Christopher Wood <> Tue, 06 November 2018 02:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25BEF1294D0 for <>; Mon, 5 Nov 2018 18:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1hqJqvPQGQu3 for <>; Mon, 5 Nov 2018 18:57:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B35E1276D0 for <>; Mon, 5 Nov 2018 18:57:11 -0800 (PST)
Received: by with SMTP id a5-v6so8176425ioq.8 for <>; Mon, 05 Nov 2018 18:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+YkrMiaQ97pyIMjNIRaXG+m+Le3KzqJxoEuW4WEZQ4E=; b=sB+j6ATZ5BI97nXi4ook+vOF6XYgA/PjZYIvsyFHKezzNhQTAx1oKSzqYqC4jBs1qN PbPFM0Dv+Ro7K4SVFg/HYC7crzIZJ9MiWnhqUMdtwNWkLTvBRvxUIEjZvQGn+n9JQmoG WuekUIV+G2PvNPptMQM+lJxz5eNgvteerIC9nSHvs8IH1xG7F+bCdx06tzhE9JbTsZv3 TQriHW9Za5lj77Z+TAe1fgSZAWmsg9d4+Ckwj60uop1pyGuibTEM9LNKsETtTDQD66SE NIarxlxCchr8F9i1UUAH5hfa0TLoXRKBdRp0UWVitlikAyIGAMHE/5QEd6pwgswpCKzv Noag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+YkrMiaQ97pyIMjNIRaXG+m+Le3KzqJxoEuW4WEZQ4E=; b=aoaO2nxIDRxIzCMZiowKGW/e9oiDHAg8BOV6g8yCJ9+eKJU5V1O4bw1sDdSIjg9ll2 MgjuwMFJMHMGqKjnUO81li+NN2vCACXWIgpzalmPnh5aPIFVOmTqDeKFrvP6NzViJn9a rfB+l57RhQ55hCns0HAf5F3KlddUCs5vsuYfeUHT95v7ODz9gxTM6q9pPJyWF4WR5Ru3 fxfg4pyMieJnwnmXC57XyNbuRzOVdGSUoNgCv6zmNLNH4DpSFhy4P4yAjQK2UPrnW6tT DsB6F46XVP8RS4qBPRoGD5nnPmt+GKUXNv3DQyZjp9CSHEh3Cdh+D95rZuHW3mxW6B/x frbQ==
X-Gm-Message-State: AGRZ1gJNgmsQR+JpDgfKQJBF4dFIMaoms+GGQHnwviCfqWogRxB4OduG eIgGIuJbRJpsrkWUdVBSCMKRhIhl/m0ToxJ3Xtian1+s
X-Google-Smtp-Source: AJdET5ea33HHAchxEEFU5Jkue0WT263zVIPmSCchssX37ghqw8b8vL3XcPW5PE9NXWGxNQ5u2TdtidHl9UWvL38nUuY=
X-Received: by 2002:a6b:9246:: with SMTP id u67-v6mr195801iod.289.1541473030554; Mon, 05 Nov 2018 18:57:10 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Christopher Wood <>
Date: Tue, 06 Nov 2018 09:56:57 +0700
Message-ID: <>
Cc: "<>" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] draft-wood-tls-external-psk-importer-00
X-Mailman-Version: 2.1.29
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: Tue, 06 Nov 2018 02:57:13 -0000

On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar <> wrote:
> I brought up an alternate construction in BKK for draft-wood-tls-external-psk-importer-00 which might have some potentially better properties. I didn't get time to explain then, so here it is:
> One issue I think with the current construction in the draft with external psk is that if the client uses the external psk with a different hash function due to configuration error, then it turns into a fatal connection error because TLS endpoints are required to tear down the connections on binder mismatch. The client does not recover until it stops using the external psk.
> An alternate approach to solve this could be to have a construction like:
> [hash of (psk identity + ImportedIdentity)] [psk identity]
> A server that uses the psk would perform the following steps during the resumption
> Negotiate the cipher suite to use
> If an external psk is used, strip off the first hash length of the psk identity where the hash length depends on the cipher suite.
> Compute the hash of pskidentity + imported identity and compare it against (2)
> If it doesn't match, don't use the PSK and fallback to full handshake.
> I think this a subtle change, because if you treat this case as if you were not willing to use the PSK, then you can ignore the binder. This might be operationally easier to deploy and reason about than a hard failure.

Thanks for writing this down! This is certainly an interesting
proposal. That said, in cases where one might use external PSKs,
failing hard seems like a fine (and probably preferred?) outcome. I'd
be happy to hear of cases where one might want to fall back to a full