Good day, I have solicited some feedback on the wording in 4.1, the MUST NOT on selecting the NULL cipher. I have feedback from members of the TLS WG, and from operators of Grid centres. My fear was that MUST NOTing the NULL cipher in the BCP may lead implementers to drop it entirely. I have a suggested new wording, with a new note, that I think would resolve this:
"Deployments of TLS to secure application-layer protocols MUST NOT negotiate the NULL cipher. Note: TLS implementations MAY retain code for the NULL cipher to allow specialised purposes like debugging, custom solutions, etc." That will make it clear that implementers are free to retain NULL (and they will), but that the purpose of the BCP is to propose secure TLS configurations to protect application-layer protocols, and for those no deployment should ever negotiate NULL. As for the feedback - it seemed to be divided into two categories: 1) Kill off the NULL cipher for all deployments. 2) There are some use cases, do not forbid it in a) implementations b) deployments The operators of Grid centres did have some very good use cases concerning a) - namely European centres having dedicated authentication mechanisms that rely on code in e.g. OpenSSL to provide exactly this NULL cipher (but MAC-ed). I can forward their exact use case if there is interest here. They did emphasise, however, that speed of encryption is no longer a concern for them. Concerning b), some people mentioned use cases like * monitoring traffic in internal networks, especially in VPN settings * IPC * some other mechanisms that seem rarely used I think implementations keeping NULL in code, but not enabling it for deployments, is the way to go and addresses all uses cases in a) and b). A note should be sufficient to make this clear. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
