> On Apr 27, 2024, at 22:46, Mahesh Jethanandani via Datatracker > <nore...@ietf.org> wrote: > > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-uta-ciphersuites-in-sec-syslog-05: 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-ciphersuites-in-sec-syslog/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 4. Paragraph 1. >> Implementations of [RFC5425] SHOULD NOT offer >> TLS_RSA_WITH_AES_128_CBC_SHA. The mandatory to implement cipher >> suite is REQUIRED to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. > I am not a security expert and do not completely understand the reason for > specifying a mandatory-to-implement algorithm. So this DISCUSS could simply be > addressed by "this is how things are done". But curious minds would still want > to know ...
It is how things are done, but we need to PICK an MTI so that we can get interoperability. > The recommendation in Section 3 of the draft is that cryptographic algorithms > will be broken or weakened over time. That implementers need to check that > cryptographic algorithms continue to provide the level of security that is > expected of them. The implication seems to be that specifying a mandatory > algorithm, e.g., TLS_RSA_WITH_AES_128_CBC_SHA, forced its implementation, and > it was wrong to do so. The blurb about algorithms weakening over time is just a truism and is in many security considerations, e.g., RFCs 9325, 8550, and serves to motivate why we need to update the MTI algorithm. TLS_RSA_WITH_AES_128_CBC_SHA was a perfectly fine algorithm back in the day (and was the MTI in TLS 1.2 at one point), but now we know it’s got some issues. > Why then is this document replacing one mandatory > algorithm with another mandatory algorithm? Would it not be better to > recommend > (rather than making it mandatory) a set of cipher suites that should be > implemented, and/or a reference made to a document like > draft-ietf-tls-rfc8447bis that recommends the latest and the greatest > cryptographic algorithms, so we are not back at doing this five years hence? Unfortunately, I think we’ll end up here regardless because you do need to pick an MTI. You might be able to avoid it by redirection, but somewhere somebody has to pick it. NOTE: that’s not being done in draft-ietf-tls-rfc8447bis, that document is added recommended column, but it’s not changing the MTI. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > More of a NIT than a comment. > > Section 3, Last paragraph. >> Finally, [BCP195] [RFC9325] provides guidance on the support of >> [[RFC8446] and [RFC9147]. > Seems like an extra square bracket. Will fix. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
