Thanks for the comments! On Wed, Oct 15, 2025 at 12:41 PM Andrei Popov <[email protected]> wrote:
> Hi Mohamed, > > Thanks for your comments. > > > Given there was a design choice to remove support in 8446/8446 bis and > reading > of the above definitions, it seems that we are more on the D side than the > N > side. > > I do not object to D, it seems appropriate. > I think the first draft of the document was written before D vs N came about. Looking back, I see this came up in this discussion: https://mailarchive.ietf.org/arch/msg/tls/fBzETzceB0b547SrZbd-U0JZiFc/ https://mailarchive.ietf.org/arch/msg/tls/a4Hdy9PT2Q9Yo8LVQKtqMQSyz5g/ https://mailarchive.ietf.org/arch/msg/tls/pPyEHhcOvnzEQya2sOfaZG2rRb8/ https://mailarchive.ietf.org/arch/msg/tls/4qmqh9pA7UzCc7l1Ms5_58bOiMw/ https://mailarchive.ietf.org/arch/msg/tls/nZrKqWTyEv4r_5Po7Bbf5MG5T08/ Looks like the conclusion at the time was "N". I have no particular feelings on this and honestly am not very up-to-date on the differences between the two. > > ## Wouldn't MUST be appropriate here? > > In my mind, SHOULD is more appropriate because it allows leeway for > compliant implementers to enable the feature, as long as they have a strong > justification. But I can live with a MUST. > Agreed that SHOULD makes more sense. It's unclear to me what MUST would mean here. At the layer of a TLS library, yeah, you probably want to disable that by default, so that the application developer can make a reasoned decision. The TLS library is usually pretty general-purpose and can't know the right choice. At the level of a particular client application or TLS service impacted by the situation, well, the developer of that probably *does* have the information already to make a reasoned decision and might quite reasonably turn it on. But is that a "TLS implementation" that is obligated to "disable it by default"? We don't formally specify the division between components of a particular endpoint, and I don't think we should. And so I think SHOULD makes sense to capture this. We're saying, yeah, you probably don't want to enable it by default because, if you're reading this document, you are probably at a layer where you want to leave it to the calling application. And so it's good for the document to nudge you in that direction. But "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course". (Maybe this particular serving software has such specialized needs that they have a bespoke embedded TLS stack, rather than reusing a general-purpose one. And maybe that bespoke TLS implementation knows it will only be used in that one serving software, which knows it wants to enable this. Adding an extra knob is then more complexity. Probably not, but plausible enough IMO to warrant a SHOULD over a MUST.) > Cheers, > > Andrei > > -----Original Message----- > From: Mohamed Boucadair via Datatracker <[email protected]> > Sent: Wednesday, October 15, 2025 12:31 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [EXTERNAL] Mohamed Boucadair's Discuss on > draft-ietf-tls-tls13-pkcs1-06: (with DISCUSS and COMMENT) > > Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-tls13-pkcs1-06: 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-tls-tls13-pkcs1/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi David and Andrei, > > Thank you for the effort put into this specification. > > Please find some points for DISCUSSion: > > # PS for a non-recommended scheme? > > CURRENT: > The "Recommended" column should be set to "N" > > I understand this is addressing a specific deployment case. I also > understand > that some interoperability is needed here to follow the guidance in the > document. Still, this is about non-recommended scheme. Any reason why are > we > publishing this as PS? > > # draft-ietf-tls-rfc8447bis says the following: > > N: Indicates that the item has not been evaluated by the IETF and > that the IETF has made no statement about the suitability of the > associated mechanism. This does not necessarily mean that the > mechanism is flawed, only that no consensus exists. The IETF > might have consensus to leave an items marked as "N" on the basis > of its having limited applicability or usage constraints. > > D: Indicates that the item is discouraged. This marking could be > used to identify mechanisms that might result in problems if they > are used, such as a weak cryptographic algorithm or a mechanism > that might cause interoperability problems in deployment. When > marking a registry entry as "D", either the References or the > Comments Column MUST include sufficient information to determine > why the marking has been applied. Implementers and users SHOULD > consult the linked references associated with the item to > determine the conditions under which the item SHOULD NOT or MUST > NOT be used. > > Given there was a design choice to remove support in 8446/8446 bis and > reading > of the above definitions, it seems that we are more on the D side than the > N > side. > > # Clear applicability Scope > > I think that a clear/dedicated section to LOUDLY describe the applicability > scope is needed here. > > # Update RFC8446/RFC8446bis > > The provisions in this draft relax what used to be disallowed in > 8446/8446bis. > This reads like an update. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # FIPS 186-4 > > ## Please add a reference > > ## s/with FIPS 186-4/with US FIPS 186-4 > > # Default > > CURRENT: > TLS implementations SHOULD disable these code points by default. See > Section 4. > > ## Wouldn't MUST be appropriate here? > > ## Which part of Section 4 is relevant to this point? I failed to see the > logic > for that reference. > > # TLS Registries > > CURRENT: > IANA is requested to create the following entries in the TLS > SignatureScheme registry, defined in [RFC8446]. > > Isn't draft-ietf-tls-rfc8447bis authoritative here for registry matters? I > would replace the 8446 citation with draft-ietf-tls-rfc8447bis. > > Cheers, > Med > > > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
