Subject: [Emu] draft-ietf-emu-eap-tls13-11: Repetition of Text

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Oct 2020 09:13:58 +0000

Hi all,

the draft contains a number of cases where text from the TLS 1.3 specification or other specifications is repeated. Often, only fragments are used, which can easily fool the reader into believing that the omitted parts do not apply. Hence, I would avoid the repetition where not strictly necessary.

Here are two examples:

Section 2.1.6:

"
   As noted in Section 4.1.4 of [RFC8446],
   the server MUST provide the supported_versions extensions and SHOULD
   contain the minimal set of extensions necessary for the client to
   generate a correct ClientHello pair.  A HelloRetryRequest MUST NOT
   contain any extensions that were not first offered by the client in
   its ClientHello, with the exception of optionally including the
   cookie extension.
"

Section 2.1.9:

"
To avoid fragmentation, it
   is RECOMMENDED to keep the sizes of client, server, and trust anchor
   certificates small and the length of the certificate chains short.
   In addition, it is RECOMMENDED to use mechanisms that reduce the
   sizes of Certificate messages.

   While Elliptic Curve Cryptography (ECC) was optional for earlier
   version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
   [RFC8446]).  To avoid fragmentation, the use of ECC in certificates,
   signature algorithms, and groups are RECOMMENDED when using EAP-TLS
   with TLS 1.3 or higher.  At a 128-bit security level, this reduces
   public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE)
   and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA).
   An EAP-TLS deployment MAY further reduce the certificate sizes by
   limiting the number of Subject Alternative Names.

   Endpoints SHOULD reduce the sizes of Certificate messages by omitting
   certificates that the other endpoint is known to possess.  When using
   TLS 1.3, all certificates that specifies a trust anchor may be
   omitted (see Section 4.4.2 of [RFC8446]).  When using TLS 1.2, only
   the self-signed certificate that specifies the root certificate
   authority may be omitted (see Section 7.4.2 of [RFC5246]).  EAP-TLS
   peers and servers SHOULD support and use the Cached Information
   Extension as specified in [RFC7924].  EAP-TLS peers and servers MAY
   use other extensions for reducing the sizes of Certificate messages,
   e.g. certificate compression [I-D.ietf-tls-certificate-compression].

   For a detailed discussion on reducing message sizes to prevent
   fragmentation, see [I-D.ietf-emu-eaptlscert].
"

This entire text should be replaced by a reference to [I-D.ietf-emu-eaptlscert], which offers a more detailed discussion.
It makes no sense to just copy a fragment of the text here, particularly when we are talking about a document from the same working group written by the same authors.

An small error in the text above: trust anchors are not exchanged in the TLS handshake.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.