Re: [TLS] Pull request for session hash

mrex@sap.com (Martin Rex) Sat, 08 November 2014 01:21 UTC

Return-Path: <mrex@sap.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 205471A00DE for <tls@ietfa.amsl.com>; Fri, 7 Nov 2014 17:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 53u1NIunoxOf for <tls@ietfa.amsl.com>; Fri, 7 Nov 2014 17:21:14 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD0F1A00D7 for <tls@ietf.org>; Fri, 7 Nov 2014 17:21:13 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id C93983A374; Sat, 8 Nov 2014 02:21:11 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7D849423FD; Sat, 8 Nov 2014 02:21:11 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6EAF51AFAB; Sat, 8 Nov 2014 02:21:11 +0100 (CET)
In-Reply-To: <CABcZeBNj2n-UM-qwVH8PSV+7MgS6kNxzqQZ20J3DtfZ8tLg9-Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 08 Nov 2014 02:21:11 +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: <20141108012111.6EAF51AFAB@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SC-VqcjJhUa8v6YrJ2NsV-fSNHY
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Pull request for session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 08 Nov 2014 01:21:16 -0000

Eric Rescorla wrote:
> 
> - IMPORTANT: Because the initial handshake messages are encrypted
>   under separate keys from the application data traffic, it seems like we
>   need to have 2 sets of CCS messages or none. In anticipation of removing
>   renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88).
>   Based on conversations with Alfredo and Martin, it seemed easier
>   to remove them. Warning: analysis needed here.

Huh?

>From an implementation standpoint CCS being a seperate content type
record that is clearly visible to the record layer is one of the better
ideas of the original SSLv3 protocol.

It reduces the necessity for synchonizing the record layer and
the handshake state machine, and allows having the record layer
concatenate consecutive handshake messages into a single TLS record
automatically on the sender side.
On the recipient side, it allows the record layer to preprocess a batch
of incoming TLS records without having to wait for the handshake message
state machine (some TLS stacks create a seperate TLS record for each
handshake message).

-Martin