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

Hubert Kario <hkario@redhat.com> Tue, 22 March 2016 10:57 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 1DCD912D538 for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 03:57:35 -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 HP1-p-tlPwF2 for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 03:57:33 -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 CD6AB12D5D6 for <tls@ietf.org>; Tue, 22 Mar 2016 03:57:33 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 8DC5A46214; Tue, 22 Mar 2016 10:57:33 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MAvWCY018405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 06:57:33 -0400
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 22 Mar 2016 11:57:31 +0100
Message-ID: <1516479.oKZilPeJ5Q@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C29525@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C29525@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1704982.1iP4WAkRij"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wdvlAbqThwFTrpi6mrbIBSu0_VE>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Tue, 22 Mar 2016 10:57:35 -0000

On Tuesday 22 March 2016 09:55:07 Peter Gutmann wrote:
> Hubert Kario <hkario@redhat.com>; writes:
> >it doesn't explain where this "RSA-SHA-256" is used. IMHO it is
> >ambiguous.
> >
> >The "no MAC truncation" is also not explicit about what the sizes
> >should be.
> Well can you suggest some wording?  I can't see how much more
> unambiguous a statement like "no MAC truncation" can be.

The Finished hash comes from PRF, which in turn comes from P_hash 
construct which has practically unlimited output. The MAC is not 
truncated there, the PRF output is, because it must be, as it is 
defined.

I was thinking of something like the following:

  The length of verify_data (verify_data_length) in the Finished message
  MUST be equal to the length of output of the hash function used as the 
  basis of the PRF selected for the ciphersuite. That is, in case of 
  SHA-256 based PRF 32 octets MUST be used. This overrides the 
  requirement from Section 7.4.9. of RFC 5246 that all ciphersuites 
  defined at that time have verify_data_length of 12.
-- 
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