Re: [TLS] MITM Attacks on Client Authentication after Resumption

Nico Williams <> Tue, 04 March 2014 05:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 88D211A0359; Mon, 3 Mar 2014 21:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.753
X-Spam-Level: *
X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dGs3kgq8wSk9; Mon, 3 Mar 2014 21:11:39 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 47C771A0353; Mon, 3 Mar 2014 21:11:39 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id CEF1E594058; Mon, 3 Mar 2014 21:11:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=XQF+MXius5daosiIjXC9 P2VviNc=; b=uZb65MuRO0Nfyb3dC9sVS5iq8CqyhWooO4a+4fsEjJTKnwhE+PBv fX8XE9fTGSIp1mCh+gQiajn2A0R8TZThh1jQiJB6ZQiZoHweErzm9FQGTya+uyOi njXaue/ZNhK1o4USEb7O//2wYF2IuVh7bfITYRrx8k/JUBKxqcOFbpo=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 5A04C594055; Mon, 3 Mar 2014 21:11:35 -0800 (PST)
Received: by with SMTP id u57so2473605wes.36 for <multiple recipients>; Mon, 03 Mar 2014 21:11:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fMceg/6I3G79e6TQQMr4zUOAs0/ugwa2m2Ysj6UkeDo=; b=JstpNq1zucLpVqrNXG75dX/DW6//vweVg6CL6ONtBZG3h9A/UoTILpsW4k9kuPqQd4 RKTN+z0gGGis79V9zKtlMy4/r/Gr9cSuUf+a+QbeCHDFN0/QaJdsXgcJahk6hMffATMK Aa0Dcpv+WzW8mF1jvdzR+v7uAqFiQrqxcd2Ki6rBH+S2oE+3Ch13EDUplzZcO3f298Fk 2L6DPJ+tjTC50nJvzvLkigsZXeIc6KLHV6e5DYhZjzJmdkyENiGoXtKNrA6/WLON79SN kj7PobSLytKGCzt2sGeiMkB/tb92+AifN4Esq13TSZK1HfYMck1SCBpix5dYaN+G+v59 /ZAQ==
MIME-Version: 1.0
X-Received: by with SMTP id l15mr24212322wjq.40.1393909894084; Mon, 03 Mar 2014 21:11:34 -0800 (PST)
Received: by with HTTP; Mon, 3 Mar 2014 21:11:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 3 Mar 2014 23:11:34 -0600
Message-ID: <>
From: Nico Williams <>
To: Adam Langley <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>, "" <>
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
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: Tue, 04 Mar 2014 05:11:44 -0000

[Cross-posting to  Please drop one of tls or kitten
when responding.  For KITTEN readers, see the TLS list archives,
there's an MITM vulnerability when using tls-unique in conjunction
with session resumption.]

On Mon, Mar 3, 2014 at 4:07 PM, Adam Langley <> wrote:
> On Mon, Mar 3, 2014 at 4:07 PM, Andrei Popov <> wrote:
>> It appears that the attack described is only feasible when two
>> implementation defects are present:
> That's not an unreasonable characterisation of the renegotiation-based
> attacks, but the problem with tls-unique is more fundamental.

The problem for tls-unique is more fundamental indeed, and Andrei's
characterization is not applicable.

We should talk about how to fix tls-unique.  The best fix may be to
keep track of the original (non-resumed) connection's tls-unique CB
and add that to the resumed connection's tls-unique CB.  This requires
adding to the session cache on the client side.

In the short-term, client and server applications should not permit
session resumption prior to channel-bound authentication (if using
tls-unique).  Except that, of course, how is the application to know
if session resumption is involved?  Assuming that it can't know or
prevent the use of session resumption, I'd say that tls-unique is just
simply not to be used.  We should publish a new tls-unique that
doesn't have this problem.