Re: [TLS] draft-gutmann-tls-eccsuites

Hubert Kario <hkario@redhat.com> Tue, 08 July 2014 12:58 UTC

Return-Path: <hkario@redhat.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 D2A3C1B2837 for <tls@ietfa.amsl.com>; Tue, 8 Jul 2014 05:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 E0Abr6oHZLuK for <tls@ietfa.amsl.com>; Tue, 8 Jul 2014 05:58:32 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id 814BA1B2830 for <tls@ietf.org>; Tue, 8 Jul 2014 05:58:32 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s68CwSo7001406; Tue, 8 Jul 2014 08:58:29 -0400
Date: Tue, 8 Jul 2014 08:58:27 -0400 (EDT)
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <2138402117.7478111.1404824307081.JavaMail.zimbra@redhat.com>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DED552A@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C738DED552A@uxcn10-tdc06.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.12]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922)
Thread-Topic: [TLS] draft-gutmann-tls-eccsuites
Thread-Index: Ac+ao4SLCSsYr4f8TkevRphBmdYRTRgjEoXB
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_hf1Lmnxffz255iiBA94-0TdTPw
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] draft-gutmann-tls-eccsuites
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: Tue, 08 Jul 2014 12:58:35 -0000

----- Original Message -----
> From: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>
> To: "<tls@ietf.org>" <tls@ietf.org>
> Sent: Tuesday, July 8, 2014 1:55:31 PM
> Subject: Re: [TLS] draft-gutmann-tls-eccsuites
> 
> Henrik Grubbström <grubba@gmail.com> writes:
> 
> >Have you considered the following note in RFC 4492 section 5.1?
> >
> >| NOTE: A server participating in an ECDHE-ECDSA key exchange may use
> >| different
> >| curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral
> >| ECDH key in the
> >| ServerKeyExchange message. The server must consider the extensions in both
> >| cases.
> >
> >As I read the above, your suites would default to imply extra restrictions
> >on
> >the possible server certificates, as you would be restricted to only the
> >same
> >curve as in the suite (eg you wouldn't be able to use a SECP521 cert with
> >TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384, as the server wouldn't
> >know if the client was capable of verifying the cert).
> 
> (It could also be argued that using a P256 cert with a P521 curve, or vice
> versa, or some similar combination doesn't make much sense

Currently there are no P256 root CA certs in Mozilla trust store. That would
force all users to use P384 leaf certificates, and by extension the AES-256 GCM,
which is unsupported by NSS (and unlikely to be actually needed by vast
majority of users).

>, why authenticate a
> 521-bit keyex with only a 256-bit signature?).

long term offline vs short term mitm attack. Or in other words, breaking
the 256 bit signature will compromise the authentication part of the connection,
breaking the 521 bit keyex will compromise the confidentiality.


Unrelated to the above:
The draft specifies few TLS1.1-and-lower compatible cipher suites, e.g.:
TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA
My understanding is that you can't use anything but concatenation of MD5|SHA1
for signing the key exchange with TLS1.1-and-lower. Am I missing something
or does it apply only the hash used for digital signatures in certificates?

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic