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.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
