> On Aug 21, 2018, at 1:29 PM, Ted Lemon <mel...@fugue.com> wrote: > > You're going to have to change what you do anyway—rather than arguing with > us why not bypass us entirely?
TLS is not just a WWW protocol. Other transport security use-cases should not have to justify their existence. It is, of course, appropriate to make sure that proposed TLS code-points that cater to specialized needs are well thought out and include suitable security considerations. It is also reasonable to check that the requirements are not already met without the proposed code-points. I am concerned that we are going beyond that to questioning the legitimacy of the use-cases. IPsec is rarely a practical alternative to TLS. That said, TLS-LTS (a TLS 1.2 profile) may well be a good long-term choice where TLS 1.3 is not sufficiently compatible. As for TLS 1.3, it is indeed missing both null encryption and null authentication ciphers. I've not seen any evidence that their presence in TLS 1.2 has led to either widespread support or non-negligible accidental misuse. TLS in SMTP is (still) largely unauthenticated opportunistic TLS, and in almost all cases certificate verification errors get ignored by sending MTAs. When doing opportunistic unauthenticated TLS, Postfix goes a step further and prefers ADH/AECDH cipher-suites (with TLS <= 1.2), since any presented certificates will be ignored. The null auth ciphers are automatically disabled when authentication is required. Similarly, Postfix provides either NO null encryption cipher-suites, or ONLY null encryption cipher-suites. One is unlikely to stumble into a null-only configuration by accident and not notice. With appropriate documentation, sensible default settings, and configuration interfaces that make good choices easy and bad choices more difficult, one can safely provide support for non-mainstream use-cases. This is not to say that null encryption ciphers for TLS 1.3 are unconditionally good, their specification would need to provide sound security considerations and be fit for purpose. But I do think that we should not reject the proposal out of hand. -- -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls