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= 40ra.rockwell....@dmarc.ietf.org> 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 <resea...@bensmyth.com> > *Sent:* Thursday, February 4, 2021 9:22 AM > *To:* <tls@ietf.org> <tls@ietf.org> > *Cc:* ncamw...@cisco.com; Jack Visoky <jmvis...@ra.rockwell.com> > *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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
