Hi Peter,
> -----Original Message-----
> From: Peter Saint-Andre <stpe...@stpeter.im>
> Sent: 14 July 2022 16:07
> To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>
> Cc: draft-ietf-uta-rfc7525...@ietf.org; uta-cha...@ietf.org; uta@ietf.org;
> le...@sunet.se
> Subject: Re: Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with
> DISCUSS and COMMENT)
>
> 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
But is "Implementations MUST support TLS 1.2 {{!RFC5246}}." really right?
Shouldn’t this be "Implementations MUST support TLS 1.2 {{!RFC5246}} or a later
version"? Otherwise, protocols like QUIC would presumably not be compliant
with this BCP if they only support TLS 1.3? Or alternatively, this could
probably be stated as "Implementations MAY support TLS 1.2 {{!RFC5246}}".
>
> > (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).
Okay.
>
> > (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
Okay, I still think that the proposed text isn't quite right - why would an
administrator need to configure it, if it used by the implementation?:
Current:
When a TLS-only
communication method is available for a certain protocol, it MUST
be used by implementations and MUST be configured by
administrators, in preference to a dynamic upgrade method.
Perhaps something like the following might be better:
When available, implementations MUST default to using a TLS-only communication
method in preference to any dynamic upgrade method. For legacy implementations
defaulting to a dynamic upgrade method, then administrators SHOULD(*) configure
the protocols to only use the TLS-only communication method over any dynamic
upgrade method and MUST advise service users to directly use the TLS-only
communication methods (e.g., for IMAP mail server settings).
(*) Perhaps this could be a MUST, but that would seem likely to be hard to
follow if that would break lots of customers ...
>
> > (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.
Okay.
Thanks,
Rob
>
> Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
