Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Ralph Holz <holz@net.in.tum.de> Sun, 22 September 2013 14:51 UTC

Return-Path: <holz@net.in.tum.de>
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 9D52021F9E98 for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 07:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.528
X-Spam-Level:
X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV06V9yhwoPN for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 07:51:30 -0700 (PDT)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6821F9E91 for <tls@ietf.org>; Sun, 22 Sep 2013 07:51:29 -0700 (PDT)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 3698480B92; Sun, 22 Sep 2013 16:51:28 +0200 (CEST)
Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id CC86B80B8C for <tls@ietf.org>; Sun, 22 Sep 2013 16:51:27 +0200 (CEST)
Message-ID: <523F0426.4010901@net.in.tum.de>
Date: Sun, 22 Sep 2013 16:52:22 +0200
From: Ralph Holz <holz@net.in.tum.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
CC: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DA10F.7010308@stroeder.com> <523EEAC2.7010707@net.in.tum.de> <6F1E2BE6-23D0-4F6C-A999-07986DB24AD5@mac.com>
In-Reply-To: <6F1E2BE6-23D0-4F6C-A999-07986DB24AD5@mac.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 22 Sep 2013 14:51:35 -0000

Hi,

> Parameter negotiation seems to be a reasonable (obvious?) bridge to
> higher levels of security. The fact that the server (or the client,
> and even sometime a MITM) can reject these higher key lengths seems
> to be OK with me, the client can choose that to fail a connection
> instead of accepting being downgraded. Even if this results in
> additional round trips, this would be something that people will work
> at removing.
> 
> The following is probably a naïve attempt at a compromise.

[...]

That wouldn't be the scope of the BCP. As Yaron has stated, the aim is a
recommendation that can be followed with what we have, striking a
compromise between PFS (near-must), support in software, and security of
AES. We leave the definition of new extension, or use thereof, to other
drafts.

When we're talking about other ciphers, I'd personally much rather see
Peter's proposal of encrypt-then-MAC, although not as an extension, please.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF