Hi Sean, Thanks for that education. Will clear my DISCUSS.
> On Apr 30, 2024, at 10:03 AM, Sean Turner <s...@sn3rd.com> wrote: > > > >> 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. Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
