Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

Watson Ladd <> Sat, 19 March 2016 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01F9012D560 for <>; Sat, 19 Mar 2016 07:51:03 -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 cDavgt34RBt7 for <>; Sat, 19 Mar 2016 07:51:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39FD012D556 for <>; Sat, 19 Mar 2016 07:51:01 -0700 (PDT)
Received: by with SMTP id q138so81032301vkb.3 for <>; Sat, 19 Mar 2016 07:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=fyRNMJRl6aAOn5KSLKuyEnqflPnMHI2mWvoVtt2NXjM=; b=uR4cpXOoYcV2Ao1D4kpUb3QruHboxO76PllLrYTVl/ulfov7g4KZ1Lpz8vYMAewLZu v4/sSGsqwg/YXf2QFqpyVSiYUcKX0V3H7OSAhTGeVAdqSa1aDzBm46cMz8V/8e8KQJKR uDqNqgoHWoaMnrsD6cvjO3kSkRGeLLSelanuMPthgEGVNHJJXcFVd4VB5Z/aO31W4KpP Tp8VUPlgw2cUEtK8ju6l7BtV54NPNu+r1toLs1oJZYIdJB9YuXSbMx/t99YNNxt+I+e9 taFvAB4jAYloJFblOOhGTxi2YX9Y4NgiBcaoDTJqfCgCKgcLbNqMk5EDX2UwcN/UadQ9 aT3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=fyRNMJRl6aAOn5KSLKuyEnqflPnMHI2mWvoVtt2NXjM=; b=dtfTr88QvGObwWpaWYbxMXisWHhCgTYUejxYKlw18kOTrp6La4jT9mjezc/d6KYzo2 hQzZ5g1pRCw4oRjTypNH1dhto4FyZ9DDQXzmp07FBziUVw6ruoQPGvDwXRTsrEV36+hA tvOzw8gaODUegOmkNu1cp98BSXz88Fw2Qd4DE4rmTo9PDR5GYTeCmydul8bo+wkg1oFL 4Wh/XySoc1TvJ0l09h+AK8IjEYdCze1MQjZxaDA2F2iceWb6YENvvOSF1u7gOCgRGaoE 6LXIbIGX4prU8QINrB5uPmr5yPOxyukvB2wpYGmFd6JrWwWnOz3HXBKK677sXkIiNI2B Qs+Q==
X-Gm-Message-State: AD7BkJJ25br87qok0yPOTMkHt2jptHu/eOJ8n94nKS3ufQHPWhHkQD9HuJx58zAaU4YvCsZRlNZAIOGMpm9OwQ==
MIME-Version: 1.0
X-Received: by with SMTP id l3mr23617296vke.68.1458399060155; Sat, 19 Mar 2016 07:51:00 -0700 (PDT)
Received: by with HTTP; Sat, 19 Mar 2016 07:51:00 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sat, 19 Mar 2016 07:51:00 -0700
Message-ID: <>
From: Watson Ladd <>
To: Peter Gutmann <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] History of TLS analysis (was Re: 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: Sat, 19 Mar 2016 14:51:03 -0000

On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann
<> wrote:
> Watson Ladd <> writes:
>>Then use a padding extension that solves all problems, instead of relying on
>>a side effect of CBC mode.
> It's not a "side-effect of CBC mode", CBC mode allows padding packets, GCM
> doesn't, see Colm MacCárthaigh's recent post on the topic.

GnuTLS is the only implementation that pads to more than 16 byte boundaries
>>Why do we want this to look different from TLS, instead of a subset of widely
>>deployed things ala UTA?
> CBC mode ciphers have been part of TLS since SSL 2.0 (AFAIK) in 1994, I don't
> know if SSL2 allowed for packet padding but 3.0 certainly did, so it's hardly
> a major change.

It's not the CBC modes that's the change, but the EtM extension.
>>What is your master secret change solving?
> Preventing manipulation of DH/ECDH parameters.

It's not immediately clear that it does so correctly. All data that
affects the interpretation must be in the master secret, and I think
that includes some data you haven't yet hashed. EMS we know gets this
>>Your draft claims that verifying signatures before sending will address an
>>ECC security threat. I don't see what threat that addresses
> The fact that ECC algorithms are extremely vulnerable to fault attacks, and a
> single faulty signature can leak the private key, at which point its game
> over.

The same fault attack commonly works on embedded implementations for
ECDH. Except here the attacker just sends a point off the curve,
instead of inducing a fault in the signature routine. RSA signatures
with CRT optimization (commonly used on embedded devices) is also
vulnerable to similar fault attacks. I'm really not sure why you're
ignoring wrong-curve attacks on cached ephemerals: just add a
recommendation to not cache ephemerals.

> I don't really know how to say the following without it sounding like an ad
> hominem attack, but how much do you really know about real-world deployment
> issues for this stuff?  You seem to be arguing for all sorts of personal
> preferences based on, I dunno, abstract theorising, but you appear to be
> totally unaware of actual real-world issues.  What I'm trying to figure out
> is, how seriously am I supposed to take your comments?  Do you actually have
> any real-world deployment experience with using this stuff in the field?

Given that I'm proposing subsetting what existing implementations
already do, instead of implementing new extensions, I find it
remarkable you're arguing that my proposal is harder to deploy. As for
what I know, I'm listed in the release notes of several TLS

> Peter.

"Man is born free, but everywhere he is in chains".