Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

[Ben Schwartz <[e-mail]>]

If you are updating the text, I would recommend removing the claim about
performance.  In general, the ciphersuites specified in the text are likely
to be slower than popular AEAD ciphersuites like AES-GCM.

On Fri, Feb 5, 2021 at 5:38 PM Jack Visoky <jmvisoky=
[e-mail]> wrote:

> Hi Ben,
>
>
>
> Thanks for the feedback, I think you have some good insights. I agree that
> there are cases where mutual authentication is not required, we’ll update
> to reflect that. Same for PSKs, on thinking about this there doesn’t seem
> to be a good reason why PSKs cannot be used. We’ll make some updates to the
> draft and post them.
>
>
>
> Thanks!
>
>
>
> --Jack
>
>
>
>
>
> *From:* Ben Smyth <[e-mail]>
> *Sent:* Thursday, February 4, 2021 9:22 AM
> *To:* <[e-mail]> <[e-mail]>
> *Cc:* [e-mail]; Jack Visoky <[e-mail]>
> *Subject:* EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher
> Suites
>
>
>
> [Use caution with links & attachments]
>
>
>
> Internet-Draft "TLS 1.3 Authentication and Integrity only Cipher Suites" (
> https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-08
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-08__;!!JhrIYaSK6lFZ!4VGEXZ1YyVlF7PaLHd9fzg61-tgLBvP9317XM7khFlKZVYOSILmLuTHQR6G95fWDR-k2$>)
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>