Hi Peter, Thanks for the further information. I'm not sure whether we have quite met in the middle yet, some further comments below.
> -----Original Message----- > From: Peter Saint-Andre <stpe...@stpeter.im> > Sent: 18 July 2022 18:56 > 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 Rob, I'm circling back to an earlier point in the thread to cover all > of the issues. (Thomas and I just discussed these topics, but Yaron was > not able to join our call because of illness.) > > On 7/14/22 9:06 AM, Peter Saint-Andre wrote: > > 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 > > We've had further discussion about this and related topics, but my take > is that if, as discussed later in the thread, we carve out QUIC from the > general recommendations (because it is a special case) then the text in > that PR should be appropriate for its intended purpose (it does not > address the wider issue of changing TLS 1.3 to MUST and/or TLS 1.2 to > SHOULD). > > See also (re QUIC): > > https://github.com/yaronf/I-D/pull/460 > > >> (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). > > Unfortunately Yaron was not able to join our call, but Thomas and I > discussed it and we think there could be two different cases: > > (a) new security-focused protocols such as QUIC > > (b) new application protocols (say, for real-time collaboration) > > For (a), it definitely makes sense to use TLS 1.3 only (as noted in the > current text, QUIC uses the TLS handshake protocol with a different > record layer). Okay. But I still note that the text for this is still only SHOULD rather than MUST. I can live with this, even though I still believe that MUST would be better. > > For (b), we see reasons why it might make sense to build on top of both > TLS 1.2 and TLS 1.3 at the present time: for instance, implementations > might want to "cast a wide net" in terms of underlying library or > operating support and thus avoid the significant effort involved in > building a secure transport protocol such as QUIC. Naturally, this > advice will probably change in 7525ter a few years from now. Yes, I can see why it *might* make sense and implementations *might* want to cast a wide net, which is why I think that SHOULD is better than MUST. I.e., SHOULD means that implementations must support TLS 1.2 unless they have a good reason not to, whereas MUST means that they are required to deploy TLS 1.2 even in scenarios where they know that all clients support TLS 1.3, and don't want to pay the additional administration overhead of safely deploying and maintaining TLS 1.2 ... However, I think that I've stated my opinion, and if you want to keep it as a MUST, I will acquiesce and remove my blocking discuss on this point. > > >> (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 > > At https://github.com/yaronf/I-D/pull/461 I'm proposing the following text: > > ### > > When TLS-only communication is available for a certain protocol, it MUST > be supported by implementations and MUST be configured by administrators > in preference to a dynamic upgrade method. When a protocol only supports > dynamic upgrade, implementations MUST provide a way for administrators > to set a strict local policy that forbids use of plaintext in the > absence of a negotiated TLS channel, and administrators MUST use this > policy. I appreciate that the context of this text is the upgrade case (which makes sense), but I'm still able to read this text as casting a wider net than hopefully intended. I.e., I'm still concerned that someone could quote this text to say that unencrypted comms is strictly not allowed anywhere, whenever a TLS version of the protocol exists, and whilst I entirely agree that using TLS is appropriate in the vast majority of places, I'm not convinced that is everywhere. Hence, I wonder whether we could restructure the first sentence to ensure that it's scope if focused purely on the upgrade scenario. I.e., I suggest something like the following for the first sentence: "When a protocol defines both a dynamic upgrade method and a separate TLS-only channel, then the separate TLS-only channel MUST be supported by implementations and MUST be configured by administrators to be used in preference to the dynamic upgrade method." Thoughts? Thanks, Rob > > ### > > > > >> (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. > > See separate note by Thomas Fossati. > > Peter _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
