IETF Logo Mail Archive

[TLS] Inconsistent TLSCiphertext definition

Yishuai Li <yishuai@upenn.edu> Thu, 27 June 2019 21:41 UTC

Return-Path: <yishuai@upenn.edu>
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 89A5B120236 for <tls@ietfa.amsl.com>; Thu, 27 Jun 2019 14:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 J1SMmIhfKwvP for <tls@ietfa.amsl.com>; Thu, 27 Jun 2019 14:41:16 -0700 (PDT)
Received: from mx0a-000c2a01.pphosted.com (mx0a-000c2a01.pphosted.com [148.163.151.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61085120298 for <tls@ietf.org>; Thu, 27 Jun 2019 14:41:15 -0700 (PDT)
Received: from pps.filterd (m0128479.ppops.net [127.0.0.1]) by mx0a-000c2a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x5RLeApq028607 for <tls@ietf.org>; Thu, 27 Jun 2019 17:41:15 -0400
Received: from fox.seas.upenn.edu (renard.seas.upenn.edu [158.130.71.129]) by mx0a-000c2a01.pphosted.com with ESMTP id 2t9j15s7aw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Thu, 27 Jun 2019 17:41:15 -0400
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (authenticated bits=0) by fox.seas.upenn.edu (8.15.2/8.15.2) with ESMTPSA id x5RLfCJI011496 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Thu, 27 Jun 2019 17:41:13 -0400
Received: by mail-io1-f43.google.com with SMTP id h6so8142542ioh.3 for <tls@ietf.org>; Thu, 27 Jun 2019 14:41:12 -0700 (PDT)
X-Gm-Message-State: APjAAAVqO7XtUn8IxGGtT49l0ORnfekEQT0hVAFdpN5m9oH1oDmGOgEl s8O0nBRXDOchfUcvLVU4/QiVc/BbG0Io8FbK8LWN
X-Google-Smtp-Source: APXvYqw66NkgoOhPPnWpOccquXUk9a9LT4mKG1xKbc9BOl5tGhQt5b5BpuzlX8mZG8BiL/9UESZsquaBUD2RU3DoySk=
X-Received: by 2002:a5d:9282:: with SMTP id s2mr6709727iom.36.1561671667406; Thu, 27 Jun 2019 14:41:07 -0700 (PDT)
MIME-Version: 1.0
From: Yishuai Li <yishuai@upenn.edu>
Date: Thu, 27 Jun 2019 17:40:19 -0400
X-Gmail-Original-Message-ID: <CABCqrhKoVZJDYFAuHmtKW=B9c7xqfr_LF8yq-84qhRr-g29TJA@mail.gmail.com>
Message-ID: <CABCqrhKoVZJDYFAuHmtKW=B9c7xqfr_LF8yq-84qhRr-g29TJA@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-06-27_14:2019-06-25,2019-06-27 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxlogscore=291 lowpriorityscore=0 mlxscore=0 phishscore=0 priorityscore=1501 adultscore=0 impostorscore=0 clxscore=1015 bulkscore=0 spamscore=0 suspectscore=3 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1904300001 definitions=main-1906270248
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hapNdiNUYpS9YhhsmqeCjk90x_8>
Subject: [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: Thu, 27 Jun 2019 21:41:24 -0000

Dear TLS working group,

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?

Thanks,
Yishuai Li

v2.23.0 | Report a Bug | By Email