Re: [TLS] TLS 1.3 Record Boundaries

Hubert Kario <hkario@redhat.com> Mon, 30 October 2017 11:21 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 99FBB13F8D3 for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 04:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.501
X-Spam-Level:
X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, 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 oM4SXjkS14wk for <tls@ietfa.amsl.com>; Mon, 30 Oct 2017 04:21:16 -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 3B72913F717 for <tls@ietf.org>; Mon, 30 Oct 2017 04:21:16 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 322536A7CC; Mon, 30 Oct 2017 11:10:48 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 322536A7CC
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (ovpn-200-18.brq.redhat.com [10.40.200.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1B17D1B7E; Mon, 30 Oct 2017 11:10:47 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 30 Oct 2017 12:10:44 +0100
Message-ID: <150941212.DozKjUoLUJ@pintsize.usersys.redhat.com>
In-Reply-To: <CY4PR21MB0120498BA401EA25CC2E439B8C470@CY4PR21MB0120.namprd21.prod.outlook.com>
References: <CY4PR21MB0120175D642F6244F04CDA358C470@CY4PR21MB0120.namprd21.prod.outlook.com> <CY4PR21MB0120498BA401EA25CC2E439B8C470@CY4PR21MB0120.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart13129913.bLXXLhTknM"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 30 Oct 2017 11:10:48 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/H2UC4QCWIbMb7IlrhzXuYg4KYXc>
Subject: Re: [TLS] TLS 1.3 Record Boundaries
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 30 Oct 2017 11:21:19 -0000

On Tuesday, 24 October 2017 02:42:01 CET Andrei Popov wrote:
> Draft-21 says:
> "Handshake messages MUST NOT span key changes.  Implementations
>   MUST verify that all messages immediately preceding a key change
>   align with a record boundary; if not, then they MUST terminate the
>   connection with an "unexpected_message" alert.  Because the
>   ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
>  messages can immediately precede a key change, implementations
>   MUST send these messages in alignment with a record boundary."
> 
> It is not clear to me what "sending messages in alignment with a record
> boundary" means. 

Reminder: a single record layer message can include multiple handshake 
messages. In particular, it can include only a part of a single message 
(beginning, middle or end).

To answer the question: it means that the last record message with handshake 
message content must have included the end part of that handshake message and 
first byte of a "key change" message needs to be the first byte of a record 
message.

Note that this is a change from TLS1.2 where for renegotiation, the 
application data could continue to be transmitted during the handshake and be 
interspaced with handshake messages, and the handshake messages could be 
fragmented.

> Does it mean that each record is either all plaintext or
> all encrypted with key X?
>
> And therefore one cannot combine, e.g.,
> ServerHello (plaintext) and EncryptedExtensions (encrypted with the
> handshake traffic key) messages in one record?

given that it's the record layer that is encryped, not the handshake message, 
I'm not sure how would you put an unencrypted and encrypted handshake message 
into a single record...
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic