[TLS] Two Decisions?

Michael StJohns <msj@nthpermutation.com> Tue, 25 November 2014 23:25 UTC

Return-Path: <msj@nthpermutation.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 3A31E1A1F73 for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 15:25:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 nwA_J077-ibj for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 15:25:15 -0800 (PST)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30981A1EF5 for <tls@ietf.org>; Tue, 25 Nov 2014 15:25:15 -0800 (PST)
Received: by mail-qg0-f45.google.com with SMTP id f51so1267889qge.32 for <tls@ietf.org>; Tue, 25 Nov 2014 15:25:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=sj+WJ18vQ9bVWA9uLASz/K+gRptpVdkQlU82Uurf7qc=; b=Z+Ct8lAtaqG86oKo5aVQDvykdSBXb2jBILFOZa1pvWLMO5nDmBPhWMQ0ghOPZ+eh/y EJyIi5XZZv5GE+CKxnxNtETKyAEiEZ7KTtRUwkDtoyqt+GBdiMg11IOddjWMSamKzN/n iKqdC0IIPwVDi/HbWOjQwVDobtIkAv7ZHinyzqL+xiqtEOi/bngOiCTKXxJfPXMlwFHk PZXGyGYRfiHpUxcbqkUWfgsABh1du4nNFCVr2TMcD7jJ40qXytYLwbJnAnOHH4BpzOeU P55S3HodEGuLzkv9AaMglZRMFzhitHwYu7H2O8WsQWIM6pn8Gyqsf45Hoie9cU8aaWXa 8jMQ==
X-Gm-Message-State: ALoCoQnuj1iBHCwQlCMV4GeJi0dEEjV+ow+ptfUbvWPspKmTHzofSGVPri5Vp71jPPROZid0z5u1
X-Received: by 10.140.81.6 with SMTP id e6mr5875697qgd.90.1416957914907; Tue, 25 Nov 2014 15:25:14 -0800 (PST)
Received: from ?IPv6:2601:a:2a00:381:90e2:9268:c74c:cd55? ([2601:a:2a00:381:90e2:9268:c74c:cd55]) by mx.google.com with ESMTPSA id n5sm2447875qat.13.2014.11.25.15.25.14 for <tls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Nov 2014 15:25:14 -0800 (PST)
Message-ID: <54750FDC.5040909@nthpermutation.com>
Date: Tue, 25 Nov 2014 18:25:16 -0500
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RaeVmUZv3A_VA318AxPi6SFC0Kw
Subject: [TLS] Two Decisions?
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, 25 Nov 2014 23:25:17 -0000

First item:

A/O TLS 1.2 the PRF function changed to be negotiable.   During 
discussions for things like session hash, the question was brought up 
(or at least I brought it up) as to whether or not the PRF function 
always needed to be a hash function (vs say a block cipher function) and 
I think the general consensus was that it was too difficult to remove 
due to its use in the finish message and session hash.   Would that be a 
fair assessment?  And if so, should text be added to make this clear?  
(Specifically, the PRF negotiation specifies a hash, and the KDF and 
various other derived functions are based on the HMAC construct of that 
hash.)

[Side comment - as I've stated before, I really would have liked to have 
the possibility of having a block cipher only PSK TLS implementation, 
but I think that given the general trend toward PFS suites which have 
public key type requirements, I would guess that that ship has sailed, 
even in the constrained device space.]

Second item:

The Master Secret has always been 48 bytes long.  A/O TLS1.2 wouldn't it 
make more sense to have the output of the Pre-Master Secret to MS key 
derivation be a key of the native length for the KDF function?  E.g. 64 
bytes for HMAC SHA256?

Right now, each round of the PRF function produces 32 octets (assuming 
HMAC-SHA256) each round so the function is run twice to get 64 octets, 
then left truncated to get 48 octets of the Pre Master Secret.  When you 
get to the MS to session key negotiation, the 48 octets is right zero 
padded back to 64 octets in the first step of the HMAC setup.

Of course for other SHA functions, the block size is larger - 128 octets 
for SHA384, etc requiring additional rounds in PMS to MS vs just padding.

This approach is slightly more complex, but does scale automatically 
with choice of cipher suite.