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

Watson Ladd <watsonbladd@gmail.com> Sat, 19 March 2016 14:51 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9012D560 for <tls@ietfa.amsl.com>; Sat, 19 Mar 2016 07:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDavgt34RBt7 for <tls@ietfa.amsl.com>; Sat, 19 Mar 2016 07:51:01 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FD012D556 for <tls@ietf.org>; Sat, 19 Mar 2016 07:51:01 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id q138so81032301vkb.3 for <tls@ietf.org>; Sat, 19 Mar 2016 07:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.31.162.3 with SMTP id l3mr23617296vke.68.1458399060155; Sat, 19 Mar 2016 07:51:00 -0700 (PDT)
Received: by 10.176.1.183 with HTTP; Sat, 19 Mar 2016 07:51:00 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2682D@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <CACsn0c=r7m94xOg0T=sxXn0JMfDq0us2iuEWi29uFEgE+r4SLw@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C2682D@uxcn10-tdc05.UoA.auckland.ac.nz>
Date: Sat, 19 Mar 2016 07:51:00 -0700
Message-ID: <CACsn0c=0-36NCXWODYMnnEvGCSS_=zkxDp4HcbpKMV+kYWR9Fg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Gr52NNY99qnBzPNbEIL5vLEg0mk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Mar 2016 14:51:03 -0000

On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz>; wrote:
> Watson Ladd <watsonbladd@gmail.com>; 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
right.
>
>>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
implementations.

>
> Peter.



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