-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3 September 2014 11:34:09 BST, Yutaka OIWA <[email protected]> wrote: >The document title is >"Recommendations for Secure Use of TLS and DTLS", >clearly applicable for the "Secure Uses". It also says >"These are minimum recommendations for the general use of TLS." > >For the purposes of such secure and general use cases, >NULL ciphers are clearly "MUST NOT" with no doubt. > >If you have any "insecure", special (non-general) use cases of TLS, >the document do not forbid you to use it, >because the document is simply not applicable. >However, such special use cases shall not make any >hindrance for making a BCP document for general use cases. > >If you worry for implementors to drop codes for special use cases, >you should say it loud to implementors, not to this document. >Also, if you worry for making it hard to use, it is the >fair cost for non-generic but supported use cases. >Security libraries easily configurable for insecure setting >is a huge security concern for general applications. > >One possible solution is to add a short note about >such special uses, saying "it's out of this document's scope, >but you should really take care of its security setting and >consequences by yourself."
+1. "MUST NOT transmit cleartext in TLS" in a BCP for general use on the internet is quite obviously the correct path. Any suggestion to the contrary is, with respect, indefensible. That does not preclude very exceptional internal configurations which really do not require confidentiality: that isn't a general internet TLS profile at all, but one that obviously will require very special attention from all participants, who are free to agree whatever they'd like, BCPs be damned. It's still not a good idea (or best current practice) to ever neglect to encrypt data where an attacker wanting it could conceivably be, however (including even internal networks, as Google, Yahoo and others have learned this year), and I'd continue to support and advocate NULL ciphersuites' complete removal from TLS 1.3 - and from all existing implementations of TLS in general use in the wild where it remains. Wanting authenticated cleartext on any network (or local socket) is in my view such a very extraordinary, unusual and/or potentially dangerous scenario that I'd actually go as far as to suggest that anyone who REALLY honestly actually needs to use it ever should actually need to explicitly patch it back in - so that all involved know thereby that, truly, here be insatiably hungry, data-eating dragons. Actually using NULL is likely to be a decision they may later regret: we owe it to them to tell them so. (They would probably be much better served, if it's really that important to them, by not using TLS but something even more efficient, say Poly1305; or perhaps even simpler, non-cryptographic, access control mechanisms if a security boundary isn't actually being crossed.) - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUBwhdGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6yhAQAKc8rEeSgcLQyJpUKR6h1Z+bvksOrCPMQ2UiBX+GtLRYfpPJOwDi 7M8olYPjMNfZXoc7WMvIq1kcU9MCDb6CZmzsAi18bRkOKoQooE85JoCVKMZswSpY Bz0kIGMnXIqz8q88Q0bU5peUSLWW8dSkd/wsjuoQngSSzSrV8aYLlQJAHZn9vRwX yYGz4H66AA3N3VNjFfwtrDuPxot7uyR7ISjcj4Yb0rs3UBPdgmlVaicZSLmnq564 qlB13D2379QpiPq6JoxisrNW1gvboNefmem+mLcHag5Smeprso4eO7BQr80h+Kpq jlHdXJBarT4kxZe6WfUO+1vN1mPT1dEtPn2iGCu00iaoxGj1BSH49Gvln4afaKvq lE2WXNnZ/Js9Y6HVQei8ES/lJZaS0553c1INZV+2XNveNykrlcQ/eil6tLF+MNlb 78Gv00wTsN2XZoLLpFFABrRfZBEoJxEe2MmL7kq92Dtg2Ugo9Nzq2UTNWOFb/1i+ pKC9xpfKTKtDLaYxKlQVBJNSyUXB7Xfaxo0DLOI6cl+OarHPujKjSIaQcTV9tpuz kznj6OulqdeWkmkMHNwVnJenucedOPtD5PIRs+LXMSZ71S2DK0ga0C6ZXqaTwkwX ZaEQq2xhrO9YdbgZ9ZhkB8oHYuJLyrSudWuzf9ZFzrozedqJ9Ls7k7Ca =bPDn -----END PGP SIGNATURE----- _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
