Hi Paul, We (authors) discussed and agree with the migration plan. The ID has been changed to reflect that.
The reason for drafting the ID and making the recommendation was to ensure interoperability. We were approached by members of an IEC working group who were going to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and not use TLS_RSA_WITH_AES_128_CBC_SHA. This was documented in the -01 draft (and in the syslog WG mailing list along with the pre-WG drafts) but was dropped after that. We've added a comment back into the -06 ID about ensuring interoperability through this migration path. Please let us know if this addresses your DISCUSS. Regards, Chris On Mon, Apr 29, 2024 at 8:59 AM Paul Wouters via Datatracker < nore...@ietf.org> wrote: > Paul Wouters has entered the following ballot position for > draft-ietf-uta-ciphersuites-in-sec-syslog-05: Discuss > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-uta-ciphersuites-in-sec-syslog/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > While the document states why it wants to SHOULD NOT > TLS_RSA_WITH_AES_128_CBC_SHA, I would like to at least have a brief > discusion > on whether this is a proper migration path. Why not offer both old and new, > with a MUST prefer the new? That seems a more viable realistic migration > path > to me. > > There are numerous statements that TLS_RSA_WITH_AES_128_CBC_SHA is "weak" > or > "insecure". As far as I know, these are a bit of an exaggeration? I think a > better description could me made to explain why we want to move away from > non-AEAD with SHA1. > > > > > >
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
