Subject: [Emu] draft-ietf-emu-eap-tls13-11: Fuzzy statements

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

Hi all,

There are plenty of places in the draft where statements are made in a somewhat sloppy manner.

Section 5.1:

" TLS 1.3 increases the number of
  cryptographic parameters that are negotiated in the handshake.
"

Increases the number of parameters compared to what?

Section 5.1:

"
TLS 1.3 forbids all algorithms with known
   weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3
   only supports cryptographic algorithms offering at least 112-bit
   security, see [RFC8446].
"

Most of those algorithms have been depreciated also with TLS 1.2
I would instead say that TLS 1.3 only uses AEAD ciphers.

 Section 2.5:

"
The Commitment Message is
   an encrypted TLS record with application data 0x00 (i.e. a TLS record
   with TLSPlaintext.type = application_data, TLSPlaintext.length = 1,
   and TLSPlaintext.fragment = 0x00).
"

Adding the note about TLSPlaintext.type, TLSPlaintext.length, and TLSPlaintext.fragment is not helpful given that both plaintext TLS records as well as encrypted TLS records use these structures. There is also a mistake in there because the TLSInnerPlaintext.type contains the application_data type (of course the TLSCiphertext.opaque_type also contains the application_data).

Introduction:
"
Privacy is mandatory ...
"

It depends what you call "privacy". TLS 1.3 offers a range of features that increase privacy protection but not all of them are mandatory to use. Example: record padding

In Section 2.1.8 you talk about privacy and say:

"
   TLS 1.3 significantly improves privacy when compared to earlier
   versions of TLS by forbidding cipher suites without confidentiality
   and encrypting large parts of the TLS handshake including the
   certificate messages.
"

This list is not exhaustive when it comes to the privacy features in TLS 1.3, as you know. If you think it is worthwhile to highlight the privacy features then why not list all of them?

Section 2.1.1:

"
SessionID is deprecated in TLS 1.3 and the EAP
   server SHALL ignore the legacy_session_id field if TLS 1.3 is
   negotiated.
"

This is misleading because the EAP server does not look into the TLS handshake messages.
Additionally, the session ID is not deprecated - it is a legacy feature that is used in the backwards compatibility mode.
FWIW you are not saying anything about the backwards compatibility mode and hence I believe you are not using it. That's something that has to be made more explicit.

Section 2.1.3:

"
The TLS PSK identity is typically derived by
   the TLS implementation and may be an opaque blob without a routable
   realm.  The TLS PSK identity is therefore in general unsuitable for
   deriving a NAI to use in the Identity Response.
"

There is no requirement in the TLS 1.3 spec that a PSK identity has to be in a NAI format. Hence, most implementations will not produce one in a NAI format. It can still be used to derive a NAI in an Identity Response if you stick a @realm to it at a different layer.

Section 2.1.6:

"
   TLS 1.3 [RFC8446] defines that TLS servers can send a
   HelloRetryRequest message in response to a ClientHello if the server
   finds an acceptable set of parameters but the initial ClientHello
   does not contain all the needed information to continue the
   handshake.
"

The TLS specification also says that this message can be used for DDoS mitigation. I think that DDoS mitigation is a valid use case in an EAP-based deployment.

Section 2.1.7:

"
  Many client certificates
   contains an identity such as an email address, which is already in
   NAI format.  When the client certificate contains a NAI as subject
   name or alternative subject name, an anonymous NAI SHOULD be derived
   from the NAI in the certificate, see Section 2.1.8.
"

>From where do you get the impression that "many client certificates" contain an identity, such as an email address?
Why does it matter whether the NAI is contained in the subject name or in the alt subject name?
You refer to Section 2.1.8 regarding how to derive a anonymous NAI from the certificate and I couldn't find the text.

"
   As the certificate messages in TLS 1.3 are encrypted, there is no
   need to send an empty certificate_list and perform a second handshake
   for privacy (as needed by EAP-TLS with earlier versions of TLS).
"

Most readers are probably not familiar with the problem you are describing here.
Also, this issue is not specific to EAP-TLS; the same approach has been used in TLS (prior to 1.3) in general.

"   When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer
   and EAP-TLS server SHALL follow the processing specified by the used
   version of TLS.
"

This statement is obvious and does not say much. What else do you want to do?

"
   For TLS 1.3 this means that the EAP-TLS peer only
   sends an empty certificate_list if it does not have an appropriate
   certificate to send, and the EAP-TLS server MAY treat an empty
   certificate_list as a terminal condition.
"

In Section 2.1.5 you describe the case where the EAP peer is not authenticated. This is a second way in TLS to delay authentication of the client to a latter phase. The approach in Section 2.1.5 was declared as acceptable with reference to emergency services but this case seems to be less acceptable. While both parties in TLS exchange may send an alert for a number of reasons I am curious why you point this situation out.

Section 2.1.3:

"
When EAP-TLS is used with
   TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism
   compatible with that version of TLS.
"

This is a meaningless statement. What else do you want to do? You cannot use the session resumption mechanism of TLS 1.3 in 1.2.
Section 5.8:

"
   Tracking of users by eavesdropping on identity responses or
   certificates is a well-known problem in many EAP methods.
"

I would not only focus on users because EAP methods are also used by devices.

Section 5.9 talks about pervasive monitoring and does not add any new content beyond what is already said in the privacy section. Could you merge the two?

Section 5.10 talks about discovered vulnerabilities of earlier versions of TLS. It should be explicitly stated that these vulnerabilities are not about TLS 1.3. The text then goes on and says

" The use of TLS 1.3 mitigates most of the known attacks. "

Which attacks are not mitigated in TLS 1.3?

Section 2.1.9:
"
   Including ContentType and ProtocolVersion a single TLS record may be
   up to 16387 octets in length.
"

This is true if you do not use the Maximum Fragment Length Extension or the Record Size Limit extension.
The question is therefore: why don't you want to use them?

Section 5.6:

"
   EAP-TLS is typically encapsulated in other protocols, such as PPP
   [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
"

EAP-TLS is encapsulated into EAP, which is then encapsulated into other protocols (such as RADIUS, Diameter, etc.).

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.