Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-external-psk-guidance-03.txt> (Guidance for External PSK Usage in TLS) to Informational RFC

[John Mattsson <john.mattsson=40ericsson.com@xxxxxxxxxxxxxx>]

Hi,

 

I think this is a great document with a lot of good information.

 

 

I think some things that should be more positive:

 

-- For both PSK authentication and PSK key exchange without (EC)DHE the bad security properties such as lack of identity protection and lack of forward secrecy can be overcome by using one-time PSKs. External PSKs with short lifetimes are quite common in many real deployments. I think this should be mentioned.

 

-- I think quantum resistance should be mentioned earlier in the document. Quantum resistance is a security property, not use a use case.

 

 

Some things that should be more negative:

 

-- In the list in 4.1 you can add

  "4.  Any group member can blame any other group member."

 

 

Other comments:

 

-- "then PSK-only key establishment modes are secure against both active and passive attack."

  I think this you need to describe the exact attacks you have in mind rather than use the work "secure". My view would be that acceptable security in 2021 includes both identity protection and forward secrecy. But more on a system level, then necessarily by TLS itself.

 

 

-- "DH"

  I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher suites in obsolete versions of TLS.

 

 

-- "As discussed in Section 6, there are use cases where it is desirable

   for multiple clients or multiple servers to share a PSK."

 

  "However, as discussed in Section 6, there are application scenarios

   that may rely on sharing the same PSK among multiple nodes."

 

Unless you have any real deployments to share, I think this should be reformulated. These are Gedankenexperiments used to illustrate the attack, not real-world applications. I would reformulate and remove "desirable", group PSKs should be very much discouraged. Suggestion:

 

"As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] describes scenarios where multiple clients or multiple servers share a PSK."

 

Cheers,

John

 

From: TLS <tls-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx>
Date: Friday, 29 October 2021 at 18:18
To: IETF-Announce <ietf-announce@xxxxxxxx>
Cc: tls@xxxxxxxx <tls@xxxxxxxx>, draft-ietf-tls-external-psk-guidance@xxxxxxxx <draft-ietf-tls-external-psk-guidance@xxxxxxxx>, kaduk@xxxxxxx <kaduk@xxxxxxx>, tls-chairs@xxxxxxxx <tls-chairs@xxxxxxxx>
Subject: [TLS] Last Call: <draft-ietf-tls-external-psk-guidance-03.txt> (Guidance for External PSK Usage in TLS) to Informational RFC

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Guidance for External PSK Usage in TLS'
  <draft-ietf-tls-external-psk-guidance-03.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2021-11-19. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document provides usage guidance for external Pre-Shared Keys
   (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
   This document lists TLS security properties provided by PSKs under
   certain assumptions, and then demonstrates how violations of these
   assumptions lead to attacks.  This document discusses PSK use cases
   and provisioning processes.  This document provides advice for
   applications to help meet these assumptions.  This document also
   lists the privacy and security properties that are not provided by
   TLS 1.3 when external PSKs are used.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/



No IPR declarations have been submitted directly on this I-D.





_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call