Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario <hkario@redhat.com> Fri, 18 March 2016 19:13 UTC

Return-Path: <hkario@redhat.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 3D67312D505 for <tls@ietfa.amsl.com>; Fri, 18 Mar 2016 12:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ahBW7T2orv83 for <tls@ietfa.amsl.com>; Fri, 18 Mar 2016 12:12:59 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B9412D5D5 for <tls@ietf.org>; Fri, 18 Mar 2016 12:12:59 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3B12BD4E62; Fri, 18 Mar 2016 19:12:59 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2IJCvDY025231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2016 15:12:58 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Fri, 18 Mar 2016 20:12:52 +0100
Message-ID: <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.4-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <CACsn0cks1tvdcYkVRj9r3TZe1GEcNA5f2x14PQntk3j1Ws+rPg@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2831036.68QhK05a0G"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 18 Mar 2016 19:12:59 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rXfcbm2DXSJuVGYP1TJt_U-LV0Y>
Subject: Re: [TLS] 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: Fri, 18 Mar 2016 19:13:01 -0000

On Friday 18 March 2016 08:57:26 Peter Gutmann wrote:
> Watson Ladd <watsonbladd@gmail.com>; writes:
> >Likewise, this draft modifies the way the master secret is computed,
> >despite a widely implemented different solution to the problem,
> >namely the EMS triple handshake fix.
> 
> Firstly, that solves an entirely different problem, and secondly I
> don't recall ever seeing EMS support in any embedded device, it may
> be widely implemented in Windows and OpenSSL but I don't know how
> much further it goes.

it may solve a different problem, but its solution is a superset of what 
you propose

I haven't seen support for X9.42 DHE parameters or selective mixing in 
of them to master secret in embedded devices either...

you modify behaviour of Master Secret calculation one way or another, 
let's do this in a way that is interoperable with other implementations, 
not add a third way to do that

also, if it really is supposed to be Long Term Support, why it doesn't 
say anything about implementation explicitly being able to handle big 
key sizes? both RSA and DHE?

I might have missed, but where is the specification of the acceptable 
signature algorithms (hash especially) on Server and Client Key Exchange 
messages?

Finally, I'd prefer the tls-lts to mostly say "see those other 
extensions? I really do mean it" + some pleasantries like the "no 
rehandshake".
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic