Re: [TLS] An SCSV to stop TLS fallback.

Watson Ladd <watsonbladd@gmail.com> Sat, 07 December 2013 06:50 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07121AE286 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 22:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 2uUZBIoE-3ne for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 22:50:37 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 062991AE281 for <tls@ietf.org>; Fri, 6 Dec 2013 22:50:36 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id z12so1512654wgg.3 for <tls@ietf.org>; Fri, 06 Dec 2013 22:50:32 -0800 (PST)
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-type; bh=VwqwQ2DTOcAWwBDBwi/PeURdQ0V+MB4E44NC11cKEKA=; b=vSEh6Z8F4+I/uC9BbA3eIcmPS07E7AYNfoo1u4E5JcKfUBqcRSxfVTKgEpzVSFbiaM pEyh6b2C1cTB4fpnbID0zuJyPgUfYF9QiaRMACjT+/rBvlRaEMH1u5XiRj0RJZNuuXz/ XueXqcLh4SFUFQeH3CC3N/gtovF4wPtf4B09SdCYIOOJxyY1LHHiBE6YToHDvNxMvsSb d2B0UMoKn4miSno4Ka6F/QjUKIJIYDIYRDSeRLXrmaVJKu21Y43GE2R2SwAb8BGGhJJV H+orlrKis+ojq9dNwZL6IUE5M0/tPenwswExDsnOya7ysXR0beIWpLm3D+tjFd1VhimL fIjQ==
MIME-Version: 1.0
X-Received: by 10.180.13.242 with SMTP id k18mr5743173wic.44.1386399032525; Fri, 06 Dec 2013 22:50:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 6 Dec 2013 22:50:32 -0800 (PST)
In-Reply-To: <20131207064254.4B0551AB3B@ld9781.wdf.sap.corp>
References: <CACsn0cnOoeELzdaKBJcD4cagXCy+OkT+WU3z4MAt1sPJuq7PCw@mail.gmail.com> <20131207064254.4B0551AB3B@ld9781.wdf.sap.corp>
Date: Fri, 6 Dec 2013 22:50:32 -0800
Message-ID: <CACsn0c=EpWn5yB1Y2zjBywDmYJ2FeqJ0yBC+nuTSBmj1yWVQ+w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 07 Dec 2013 06:50:39 -0000

On Fri, Dec 6, 2013 at 10:42 PM, Martin Rex <mrex@sap.com> wrote:
> Watson Ladd wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> To clarify.
>> >
>> > Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
>> > thing the client might be "loosing" is a little performance, and
>> > that AEAD can not currently be negotiated and used unless
>> > ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
>> > of the specification(s) that could be easily fixed.
>>
>> I am assuming you are discussing the modes as specified and
>> implemented in TLS? In that case you are dead wrong.
>> Lucky 13, BEAST, and even if we drop all that no protocol depending
>> both on SHA1 and AES can be stronger than one depending
>> on AES alone.
>
> Lucky 13 and BEAST are completely irrelevant for the majority
> of usage scenarios, and there's even a simple 1/(n-1) record splitting
> workaround for BEAST for those with paranoia.
Paranoia is a requirement for this WG.
>
> I don't know what you mean by "AES alone", but if you are refering
> to "AES-GCM", that isn't AES alone, but AES in combination with GHASH,
> and HMAC-SHA1 beats the security of GHASH by a huge safety margin.
No, GHASH has an unconditional security guarantee, while HMAC is only
conjectured to be secure.
If you break AES-GCM you break AES, and hence AES-CBC-SHA1.
AES-CBC-SHA1 also falls if
HMAC fails.
>
> -Martin



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin