[Uta] Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-uta-rfc7525bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document, I think that it is a helpful update.  Disclaimer, I'm
not a security expert, but I would like to discuss some of the RFC 2119
constraints that have been specified please:

(1)
I find some of the 2119 language to be somewhat contradictory:

  *  Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].

  *  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
     negotiate TLS version 1.2 over earlier versions of TLS.

The second sentence implies that a TLS 1.2 is allowed to negotiate earlier
versions of TLS, but a previous statement indicates that this is not allowed. 
A similar contradiction appears for DTLS:

   *  Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].

   *  Implementations MUST support DTLS 1.2 [RFC6347] and MUST prefer to
      negotiate DTLS version 1.2 over earlier versions of DTLS.

(2)
           *  New protocol designs that embed TLS mechanisms SHOULD use only TLS
              1.3 and SHOULD NOT use TLS 1.2; for instance, QUIC [RFC9001]) took
              this approach.  As a result, implementations of such newly-
              developed protocols SHOULD support TLS 1.3 only with no
              negotiation of earlier versions.

Why is this only a SHOULD and not a MUST?  If a new protocol (rather than an
updated version of an existing protocol) was being designed why would it be
reasonable to design it to support TLS 1.2?  If you want to keep these as
SHOULD rather than MUSTs then please can the document specify under what
circumstances it would be reasonable for a new protocol design to use TLS 1.2.

(3)
                                                           When TLS-only
      communication is available for a certain protocol, it MUST be used
      by implementations and MUST be configured by administrators.  When
      a protocol only supports dynamic upgrade, implementations MUST
      provide a strict local policy (a policy that forbids use of
      plaintext in the absence of a negotiated TLS channel) and
      administrators MUST use this policy.

The MUSTs feel too strong here, since there are surely deployments and streams
of data where encryption, whilst beneficial, isn't an absolute requirement?

In addition "MUST be used by implementations and MUST be configured by
administrators" also seem to conflict, i.e., if the implementation must use it
then why would an administrator have to enable it?

(4)
   When using RSA, servers MUST authenticate using certificates with at
   least a 2048-bit modulus for the public key.  In addition, the use of
   the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST NOT
   be used ([RFC9155], and see [CAB-Baseline] for more details).

So, for clarity, this would presumably mean that SHA-256 is also preferred over
say SHA-512?  Is that the intention?  Or would it be better if the SHOULD
allowed stronger ciphers?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



   This document does not discuss the use of TLS in constrained-node
   networks [RFC7228].  For recommendations regarding the profiling of
   TLS and DTLS for small devices with severe constraints on power,
   memory, and processing resources, the reader is referred to [RFC7925]
   and [I-D.ietf-uta-tls13-iot-profile].

Would it be better to write "does not specify" rather than "does not discuss",
which feels a bit colloquial?

Thanks,
Rob