Re: [TLS] Inconsistent TLSCiphertext definition

Ilari Liusvaara <> Sat, 29 June 2019 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AEEB12000E for <>; Sat, 29 Jun 2019 07:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xumch7oYEgVe for <>; Sat, 29 Jun 2019 07:41:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 147C9120041 for <>; Sat, 29 Jun 2019 07:41:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA14245520; Sat, 29 Jun 2019 17:41:27 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id Tm-usGZu9Y_D; Sat, 29 Jun 2019 17:41:27 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 33C607A; Sat, 29 Jun 2019 17:41:24 +0300 (EEST)
Date: Sat, 29 Jun 2019 17:41:24 +0300
From: Ilari Liusvaara <>
To: Yishuai Li <>
Message-ID: <20190629144124.GA2471630@LK-Perkele-VII>
References: <> <20190628080054.GA2408377@LK-Perkele-VII> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] Inconsistent TLSCiphertext definition
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Jun 2019 14:41:34 -0000

On Sat, Jun 29, 2019 at 08:36:49AM -0400, Yishuai Li wrote:
> Thanks Ilari.
> Ilari Liusvaara <> 于2019年6月28日周五 上午4:01写道:
> > 1) 0x16 byte is appended to plaintext to yield TLSInnerPlaintext
> >    (since this is encrypted handshake message), together with 0
> >    trailing zeroes (for padding, there could be more).
> 1. Is it worth adding this explanation to RFC 8448? Neither
> "TLSInnerPlaintext" or "0x16" was mentioned in the context, making
> this "Informational" RFC not so informative.

Well, the RFC 8448 does not cosider how the record protection
works internally.
> 2. Is there a specific reason to structure TLSInnerPlaintext this way?
> Does it make parsing counterintuitive that the parser must know
> ContentType before locating ContentType?

Yes, to encrypt the content type of encrypted records and offer to
pad them with no extra overhead (there is no padding length field).
It was not possible to encrypt the main content type field due to
the fact that the range is not bit-aligned.

Parsing should not be that difficult:

- If outer content type is 21, it is unencrypted alert, if 22 it is
  unencrypted handshake fragment and if 23, it is encrypted record,
  that one should attempt to decrypt. If this fails, send fatal
- For unencrypted records, payload starts at byte 5 of the record
  and extends to the end.
- For encrypted records, After decrypting, scan for last nonzero
  byte. If none is found, send fatal alert.
- The last nonzero byte is true content type.
- The part of decrypt output before that last nonzero byte is the
  record payload.