Subject: [TLS] TLS 1.3 Authentication and Integrity only Cipher Suites

From: Ben Smyth <[email-masked]>
Date: Thu, 4 Feb 2021 15:21:57 +0100

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

---

From: Jack Visoky <[email-masked]>
Date: Fri, 5 Feb 2021 22:37:35 +0000

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 <[email-masked]>
Sent: Thursday, February 4, 2021 9:22 AM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]; Jack Visoky <[email-masked]>
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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 8 Feb 2021 13:21:47 -0500

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=
[email-masked]> 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 <[email-masked]>
> *Sent:* Thursday, February 4, 2021 9:22 AM
> *To:* <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]; Jack Visoky <[email-masked]>
> *Subject:* EXTERNAL: 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$>)
> 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?
>
>
>
> 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?
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 9 Feb 2021 00:41:11 +0000

>to be slower than popular AEAD ciphersuites like AES-GCM.

Uhh... when is AES-GCM faster than SHA2, except on systems with hardware
support for AES-GCM and no hardware support for SHA2?

Peter.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Feb 2021 10:57:08 -0500

Hardware support for AES but not SHA2 is extremely common.  For devices
without acceleration, ChaCha20-Poly1305 is likely to be faster than SHA256
(e.g. according to https://www.bearssl.org/speed.html).

Unless your device has hardware offload for SHA256 but _not_ for AES (a
rare combination), you can likely do AEAD faster than these integrity-only
ciphersuites.  The draft implies that performance ("latency", "processing
power") is a motivation for using these ciphers.  (It also mentions
"runtime memory footprint" and "the need to minimize the number of
cryptographic algorithms used", which are separate considerations.)

---

From: Jack Visoky <[email-masked]>
Date: Tue, 9 Feb 2021 18:26:53 +0000

Hi,

I think we discussed this in a previous thread, but I’d prefer to keep this part of the draft as is. Since IoT hardware is really diverse there are some platforms where this would be a performance gain (and others where it is not). We don’t make strong claims in this area in the draft so I think it is appropriate as is. That said, if you’d like we can add some “disclaimer” text saying this won’t apply in all cases, but I don’t think it’s appropriate to remove it completely.

Thanks,

--Jack

From: Ben Schwartz <[email-masked]>
Sent: Tuesday, February 9, 2021 10:57 AM
To: Peter Gutmann <[email-masked]>
Cc: Jack Visoky <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

Hardware support for AES but not SHA2 is extremely common.  For devices without acceleration, ChaCha20-Poly1305 is likely to be faster than SHA256 (e.g. according to https://www.bearssl.org/speed.html).

Unless your device has hardware offload for SHA256 but _not_ for AES (a rare combination), you can likely do AEAD faster than these integrity-only ciphersuites.  The draft implies that performance ("latency", "processing power") is a motivation for using these ciphers.  (It also mentions "runtime memory footprint" and "the need to minimize the number of cryptographic algorithms used", which are separate considerations.)

On Mon, Feb 8, 2021 at 7:41 PM Peter Gutmann <[email-masked]<mailto:[email-masked]>> wrote:

Peter.