Re: [TLS] Inconsistent TLSCiphertext definition

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 28 June 2019 08:01 UTC

Return-Path: <ilariliusvaara@welho.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 EDF5C120163 for <tls@ietfa.amsl.com>; Fri, 28 Jun 2019 01:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CsCfoVt14gU for <tls@ietfa.amsl.com>; Fri, 28 Jun 2019 01:01:01 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5C9120131 for <tls@ietf.org>; Fri, 28 Jun 2019 01:01:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 2ABDAC3F31; Fri, 28 Jun 2019 11:00:58 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 5dKTT03nmG4Z; Fri, 28 Jun 2019 11:00:57 +0300 (EEST)
Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 874D62308; Fri, 28 Jun 2019 11:00:55 +0300 (EEST)
Date: Fri, 28 Jun 2019 11:00:55 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Yishuai Li <yishuai@upenn.edu>
Cc: tls@ietf.org
Message-ID: <20190628080054.GA2408377@LK-Perkele-VII>
References: <CABCqrhKoVZJDYFAuHmtKW=B9c7xqfr_LF8yq-84qhRr-g29TJA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABCqrhKoVZJDYFAuHmtKW=B9c7xqfr_LF8yq-84qhRr-g29TJA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PHHobEoveJ9kcXfJ_inzeSvjVZY>
Subject: Re: [TLS] Inconsistent TLSCiphertext definition
X-BeenThere: tls@ietf.org
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." <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: Fri, 28 Jun 2019 08:01:04 -0000

On Thu, Jun 27, 2019 at 05:40:19PM -0400, Yishuai Li wrote:
> 
> RFC 8446 Section 4 Page 23 says:
> 
> > Handshake messages are supplied to the TLS record layer, where they are
> > encapsulated within one or more TLSPlaintext or TLSCiphertext structures which
> > are processed and transmitted as specified by the current active connection
> > state.
> 
> RFC 8448 Section 3 Page 8 sends a handshake record, with content type
> application_data (0x17). Should I read it as: "The handshake record is
> encapsulated within a TLSCiphertext"?
> 
> 1. If yes, RFC 8446 Section 5.2 Page 80 says:
> 
>     > encrypted_record: The AEAD-encrypted form of the serialized
>     > TLSInnerPlaintext structure.
> 
>     However, the payload does not follow the structure of TLSInnerPlaintext (RFC
>     8446 Section 5.2 Page 79), but that of Handshake (RFC 8446 Section 4 Page
>     24) instead.
> 
> 2. If no, which section of RFC8446 specifies the complete record?

The payload shown is TLSInnerPlaintext.content. It gets processed as
follows:

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).
2) The TLSInnerPlaintext is AEAD-encrypted
3) The record header is prepended (with application_data type, since it
   is encrypted).

Note that the size difference between payload and record is 22 bytes:

- 5 bytes for the record header (0x17 0x03 0x03 0x02 0xa2).
- 1 byte for the encrypted record type (whatever 0x16 encrypts to)
- 0 bytes for padding
- 16 bytes for the AES-GCM tag.

Exactly matching the amount expected.


-Ilari