Hi Martin, Thanks for the follow-up with Jean-Michel.
This looks good to me. Please see some clarifications inline. Feel free to grab whatever useful. Cheers, Med > -----Message d'origine----- > De : Martin Thomson <m...@lowentropy.net> > Envoyé : mardi 20 mai 2025 01:57 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; The > IESG <i...@ietf.org> > Cc : draft-ietf-tls-keylogf...@ietf.org; tls-chairs <tls- > cha...@ietf.org>; tls@ietf.org; Sean Turner <s...@sn3rd.com> > Objet : Re: Mohamed Boucadair's Yes on draft-ietf-tls-keylogfile- > 04: (with COMMENT) > > > Hi Med, > > I've responded to Jean-Michel. I don't think that this leads to > changes, though your suggested change to the abstract is a welcome > addition. > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm > ailarchive.ietf.org%2Farch%2Fmsg%2Flast- > call%2FWQ220gqFAyqTF5T8iVdFuTcP_l8%2F&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C4d36640295134dbb1b6908dd9730f5e4%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C638832958726752852%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=l9nbAQymdNVYh2cl > B2bxD2EnJbh0RGVDo3Rb%2BKqj6TI%3D&reserved=0 > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > ithub.com%2Ftlswg%2Fsslkeylogfile%2Fpull%2F28&data=05%7C02%7Cmohame > d.boucadair%40orange.com%7C4d36640295134dbb1b6908dd9730f5e4%7C90c7a > 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638832958726782909%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GiNvqsnR > jTuv7%2BdZStO4H4VT8fqBit8jxr9Sm5Q0Umk%3D&reserved=0 covers the > changes you suggested. > > On Mon, May 19, 2025, at 22:18, Mohamed Boucadair via Datatracker > wrote: > > In reference to the first point, I'd like to remind that BCP 195 > > includes the > > following: > > > > Nevertheless, this > > document does not discourage software from implementing > NULL > > cipher suites, since they can be useful for testing and > debugging. > > I disagree with this; see my response to Jean-Michel, linked above. > [Med] ACK. Because this is what we have right now in a BCP, my main point is actually the other part of the text you stripped: There are cases where the use of SSLKEYLOGFILE may be superior than use of NULL encryption or fallback to non-TLS. I understand that we are not making any recommendation about the use of SSLKEYLOGFILE, but it would be helpful to call out how it is different vs. the other choices. FWIW, Heikki (cced) provided a good summary of intended usage and how this does not suffer from the limitations of other methods: * https://mailarchive.ietf.org/arch/msg/opsawg/q50vS7G9XXewKtYzNjWlSSxYr8Q/ * https://mailarchive.ietf.org/arch/msg/opsawg/IoXZNjxrMTpFbjmd68q4KfKQjRM/ As discussed in that thread, some global guidance is needed rather than having each application deals with this. > > Can we mention other guards such as those mentioned in the OPSDIR > > review (e.g., right managements)? > > There's a mention of that in the security considerations: > > > Implementations that support logging this data need to ensure > that logging can only be enabled by those who are authorized. > > (There's more than that, but that's the key sentence, I think.) [Med] That part in security cons is really great. I was looking for a mention early in the document, e.g.,: OLD: For software that is compiled, use of conditional compilation is the best way to ensure that deployed binaries cannot be configured to enable key logging. NEW: For software that is compiled, use of conditional compilation is the best way to ensure that deployed binaries cannot be configured to enable key logging. Further authorization checks are discussed in Section 3. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
