Internet-Draft "TLS 1.3 Authentication and Integrity only Cipher Suites" ( https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-08) highlights TLS use cases with authentication and integrity needs, without any need for confidentiality. The draft promotes mutual authentication, but this seems unnecessary, as I'll discuss. I'm also unclear why certificate-based authentication is mandated, as I'll also discuss. Let me first summarise application scenarios.
The need to couple authentication and integrity seems clear: Neither makes sense without the other. (There's little sense in authenticating an interlocutor, without knowing whether they are communicating thereafter.) Equally, the case for dropping confidentiality seems clear: Some applications, including use cases given, simply do not require confidentiality. (It's worth noting that traffic analysis can anyhow defeat confidentiality, albeit, I'm unsure of the specifics.) The need for mutual authentication is unclear to me and seemingly unsubstantiated by use cases. For example, in the weather reporting use case, only the weather reporter need authenticate, a node seeking the report need not. Although some use cases may require mutual authentication, others seemingly do not. Given that unilateral authentication reduces computational and communication burden, whilst eradicating a class of private keys, can the draft be generalised to permit unilateral or mutual authentication? Actually, as it stands, the draft does not appear to provide mutual authentication, since TLS only provides unilateral authentication of a server by default. To ensure mutual authentication, the draft must mandate a server sending a CertificateRequest message, and a client responding with Certificate and CertificateVerify messages (rather than merely a Certificate message that does not contain a certificate). (For PSK-based key exchange, a client must include extension post_handshake_auth in their ClientHello message and a server must send a CertificateRequest after the handshake completes, but this mode isn't currently supported by the draft.) The draft mandates that "PSK data MUST NOT be sent in the handshake [due to the lack of confidentiality]," yet a standard ClientHello message sends PSK data (listing pre-shared key identifiers and key exchange modes for each) in the clear, as does a standard ServerHello message (a server-selected identifier is included). It's only a standard EncryptedExtensions message that protects handshake data, yet I can't find any PSK data that would be protected. Is PSK-based authentication viable? (I suspect a server could even securely issue a NewSessionTicket message, since such messages don't contain any particularly sensitive information, perhaps with the exception of the ticket_nonce, but even that shouldn't be sensitive, given that it merely ensures distinct pre-shared keys. That said, I haven't thought through the details.) I appreciate the work by Nancy and Jack on this draft, which covers useful application scenarios beyond the scope of the TLS 1.3 specification. Best regards, Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
