On Sun, Oct 5, 2014 at 12:26 PM, Yaron Sheffer <[email protected]> wrote: > 1. Say explicitly that opportunistic TLS is out of scope. > 2. Or say explicitly that it is in scope, and with the same requirements as > "regular" TLS. > 3. Or come up with a different set of requirements for opportunistic TLS.
I think you can just avoid mentioning opportunistic TLS in the BCP at all. How could unauthenticated TLS be in scope for a TLS BCP when it has not even been deployed yet? It isn't a current practice. > - With channel bindings, you can convert an unauthenticated TLS channel into > an authenticated one, after the fact. There's no commonly-accepted way of doing that. Regardless, it isn't a common current practice. > - Also, because we do not want to fragment the TLS ecosystem. That's exactly what unauthenticated/opportunistic TLS is doing, and that is in fact one of the biggest arguments against unauthenticated TLS. > - Lastly, an opportunistic deployment can eventually become authenticated > TLS, when DANE is introduced. DANE-authenticated TLS would be authenticated TLS, not unauthenticated/opportunistic TLS. Regardless, it is also out of scope for this BCP because it isn't a common current practice. Cheers, Brian _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
