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

[Peter Saint-Andre <[e-mail]>]

Hi Robert, thanks for the review. Comments inline.

On 7/14/22 3:37 AM, Robert Wilton via Datatracker wrote:
> 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.

Based on other reviews, I think we already have a fix for this:

https://github.com/yaronf/I-D/pull/447/files

> (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.

Although personally I'm open to MUST here, I'd like to discuss that with 
my co-authors (one of whom is offline this week).

> (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?

I believe this is a duplicate of an issue that other folks have already 
raised:

https://github.com/yaronf/I-D/issues/437

> (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?

I think we should probably say "SHA-256 or stronger", but again I'd like 
to see what my co-authors think.

Peter