[TLS] TLS 1.3 Authentication and Integrity only Cipher Suites

[Ben Smyth <[e-mail]>]

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