Hi, Thanks for the replies guys, I understand your viewpoint. I'm just worried that in the future the knobs for corner cases like deliberately turning on NULL won't be in the software/specs at all. If you are in a scenario where you can't encrypt and NULL ciphers can't be used because the software/specs don't support it, then you can't use TLS at all, not even for providing integrity and authentication.
I did notice the wordings that limit the applicability of the BCP in these kinds of cases. Anyway there's a difference between intentionally running no crypto and running a so-so crypto like RC4 with TLS; if you intentionally run crypto to provide confidentiality you might as well run the best you can. Tapio On 22.12.2014 2:51, Ralph Holz wrote: > Hi, > > +1 to Rich's answer. @Tapio, we've discussed this extensively between > members of the TLS WG and UTA WG, to the considerable chagrin of some, and > managed to reach a compromise everyone could live with. > > The current version is very carefully worded to allow operators to deviate > from the BCP in cases as you describe, while making it clear that they are > not following a best practice anymore and are on their own. We cannot list > all potential corner cases where deviating may be sensible, and I think we > should maintain that a Best Practice includes forbidding NULL. > > BTW, with other IETF efforts to forbid RC4 on the grounds that it is > insecure, it seems curious that one would allow NULL in a Best Practice. > > Ralph > > On 22 December 2014 at 10:14, Salz, Rich <[email protected]> wrote: > >> >>> So the draft-ietf-uta-tls-bcp-08 section 4.1 first MUST NOT would in my >>> view be better as SHOULD NOT, with a rationale acknowledging those cases >>> where you don't want or can't have confidentiality. >> >> No, the fact that there are places where you can't/won't do data privacy >> should not weaken the case that doing this is, in fact, a best practice. >> >> Not everyone and everything can do best practices. If they could, they >> would be common, not best. >> >> > > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
