Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Karthikeyan Bhargavan <> Sun, 20 March 2016 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E8D912D771 for <>; Sun, 20 Mar 2016 05:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J8depeKiJDNy for <>; Sun, 20 Mar 2016 05:53:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C0C012D753 for <>; Sun, 20 Mar 2016 05:53:39 -0700 (PDT)
Received: by with SMTP id p65so122088640wmp.1 for <>; Sun, 20 Mar 2016 05:53:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k6H9FOI9xykfRfvoqA2G1y20SeEbKefdX6u9DptgGFk=; b=U44haTG4tPEHNQtwdLlGxYdoAMrODk/0in+pPR7RmPFc2HhKYLVCL9JNgFvG5fVMwn CNaZvAaSTdfwzA024NINoJROt8ZAcV01iLKoV7YIBnViH9ivwpvdtGmnAGjOnISWLGd1 JNWVg4aS6zx3NFFwEWAyhtjl9Mjl6boEgZubjYbvepMLwwvkv/ixxqJ1lNreFTF6KoDb 3Y6e14Jg+SxPx75TYzBkRfzyyRn7HBWsLkwjHIVAEWm9xL1cw5xr0aK0NQ1DAyfpTH+s 90IiKvnsg22OZaP6A9IzF+qIrIV09rNGh1ptZUA4OJa2lsAIUmOEUqmzz9QzOBdch3J1 1Kig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k6H9FOI9xykfRfvoqA2G1y20SeEbKefdX6u9DptgGFk=; b=FxcToDiOcWGJu2KAoO3lHC84vz2bnVeJ3SO9rUH8by3kMfnkjmEsLbdSvJPJaU17Oi aGnGmTnnX1ktxb1KrFtHuqw8/bCj8gUckodF1+1OJhsed1KWV1UkIYNdIv/VhYPeAPOO MA9V9+WxWnPs8KIuQMSWVICULENo1wWLuKNMitsumL8pyPqns4T0ycfw4g6R91lWocvQ 760yrumDkjtfRiGRada4YXkyatqTwWWeiJQM6LiSj06eqxUJ7ZemSNcTZswO5PnFtRb3 FWnyDspnbCIPvxvWMM/Q/iA3cu5F+emhVoJaN8Ufy9cFfj09S63YrrKfoRfKa+e8OJhk e3+A==
X-Gm-Message-State: AD7BkJKBQNkjqslKqbeLzf2CuSURdCb8fEVnm9UIKKVWLwV/9Olb2ueOpNy/6c2vfCxbvQ==
X-Received: by with SMTP id qp10mr25032195wjc.138.1458478417999; Sun, 20 Mar 2016 05:53:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ux5sm20535883wjc.17.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Mar 2016 05:53:36 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Sun, 20 Mar 2016 13:53:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
X-Mailman-Version: 2.1.17
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: Sun, 20 Mar 2016 12:53:41 -0000

> So presumably instead of hashing the bare nonces for the keyex sig you'd hash
> the entire hello message that contains them?

Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want to clone the hash state,
then maybe the log up to ServerCertificate. 

I agree that the benefit of this is not so clear for known-weak/export ciphersuites which should simply be disabled.
The main advantage is that it is a uniform way to prevent potential future downgrades on things like the elliptic curve.
It also prevents some downgrade attacks on False Start in case LTS enables it (I assume it doesn’t). 

> There's an SCSV-shaped hole in the draft for that :-).

Yeah, SCSV-like mechanisms can prevent downgrades from LTS to non-LTS, but only
as long as the non-LTS version does not support weak key exchanges like export RSA/DHE.
Otherwise, the attacker first deletes LTS, then downgrades to a weak key exchange, 
then breaks it to complete and hijack the connection.

So to get the full gain of LTS, we must require LTS implementations to blacklist weak ciphers even
for non-LTS TLS 1.2 connections.