Re: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x

mrex@sap.com (Martin Rex) Fri, 08 February 2013 19:23 UTC

Return-Path: <mrex@sap.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 748A621F8BFD for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 11:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.303
X-Spam-Level:
X-Spam-Status: No, score=-10.303 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U97lZnSyMcCC for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 11:23:57 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8621F8BF8 for <tls@ietf.org>; Fri, 8 Feb 2013 11:23:56 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r18JNt7H026768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2013 20:23:55 +0100 (MET)
In-Reply-To: <51154DCF.4090407@brainhub.org>
To: Andrey Jivsov <openpgp@brainhub.org>
Date: Fri, 08 Feb 2013 20:23:55 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130208192355.359111A52E@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Feb 2013 19:23:57 -0000

It appears to have been retroactively clarified as being (2)
from your choices:

TLSv1.1   http://tools.ietf.org/html/rfc4346#section-8.1.2
TLSv1.2   http://tools.ietf.org/html/rfc5246#section-8.1.2

                                        Leading bytes of Z that
   contain all zero bits are stripped before it is used as the
   pre_master_secret.

-Martin

Andrey Jivsov wrote:
> I ran into an interoperability problem between our TLS implementation 
> and another very popular one.
> 
> The question is what exactly is the formatting  for the RFC2246 sec. 
> 8.1.2 "Diffie-Hellman" shared secret 'Z' ?
> 
> The problem arises when the most significant byte of the Z is zero. 
> Let's say that the field prime's size is 256. There are two possibilities:
> 
> 1. export the Z in the big endian format, padding it to 256 (first byte 
> in the buffer is zero)
> 2. export the Z in the big endian format, placing the result in a 255 
> byte buffer.
> 
> I would say that this should be #1, because it is the natural 
> representation of the Z. If there is a language specifying the canonical 
> encoding for the Z, I would appreciate the reference.
> 
> ( Apparently, this problem doesn't clearly manifest itself in real 
> deployments because ~ the 1/256 failure rate is masked by 
> re-negotiations at the higher protocol level. )
> 
> Thank you.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls