Re: [TLS] TLS 1.3 Record Boundaries

Peter Wu <peter@lekensteyn.nl> Tue, 24 October 2017 10:23 UTC

Return-Path: <peter@lekensteyn.nl>
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 8F45113F6F6 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 03:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 oXM5PMcnqRBw for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 03:23:24 -0700 (PDT)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F4313F0A8 for <tls@ietf.org>; Tue, 24 Oct 2017 03:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=ia2E7Y6srbZRN6T77PDMLFXu5EMGlR9SmoNFTYBspQM=; b=KA7/3jmbh33YQ4z9J79LKlbIKz4pl4fxPtWzATpg5gMhxnTLCyqzocnZAqDl/YIRVZkhACnEP9XZfKCFR4Ng477LFofYnpGNyJVPX9dbLVGMj9W4BOR4Hdmm82mROaX3/enhusaAXpMU6DfjcfFqmIv+o98YPQXAN2QPihOvLbZgV0ChX2MDl08FXZSt36prSPsct9SwrGC+4+2AQRQG1V24I5OgFgKFwWlqFVVYiZan5uKsOPASuKakBg7AUi5847oK82oPTfO3cNEKAWWCEFJgLJdlYZ0zktBURLXnjggHEr5IGM11H1/8jAw4+MzePVzv/RKgsiSYdM3qfMD1PA==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <peter@lekensteyn.nl>) id 1e6wMf-0001pU-Dx; Tue, 24 Oct 2017 12:23:21 +0200
Date: Tue, 24 Oct 2017 11:23:15 +0100
From: Peter Wu <peter@lekensteyn.nl>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: "'tls@ietf.org'" <tls@ietf.org>
Message-ID: <20171024102315.GA30630@al>
References: <CY4PR21MB0120175D642F6244F04CDA358C470@CY4PR21MB0120.namprd21.prod.outlook.com> <CY4PR21MB0120498BA401EA25CC2E439B8C470@CY4PR21MB0120.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CY4PR21MB0120498BA401EA25CC2E439B8C470@CY4PR21MB0120.namprd21.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WeT5y1vCLumu4iVzb7pqu6DjAIo>
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: Tue, 24 Oct 2017 10:23:26 -0000

On Tue, Oct 24, 2017 at 12:42:01AM +0000, 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.
> Does it mean that each record is either all plaintext or all encrypted with key X?

Yes, where key X could be the client/server handshake, traffic secret,
etc.

> And therefore one cannot combine, e.g., ServerHello (plaintext) and
> EncryptedExtensions (encrypted with the handshake traffic key)
> messages in one record?

Correct. And before you switch to a new cipher context, you MUST check
that you have no more remaining data in the record. For example, no more
data is allowed in the same record following the Server Hello. And the
record after the Server Hello, there is an encrypted record containing
Encrypted Extensions (encrypted with the server handshake secret).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl