>> It's a profile. Call it what you will. The rest of us call this a >> profile. All the more so when profiles are named in an IANA registry. >> Applications can then very trivially select an appropriate TLS profile >> using standard profile naming. > > Yeah, we don't need to argue semantics. My point is that I'd agree with a > more strict profile than what we have now as an addon, but not a more > permissive profile, as was the initial suggestion.
I think it would be wise to acknowledge the "compatibility" use case, and capture it in a profile. It would be more permissive because it provides compatibility, like SSLv3. And because SSLv3 is represented in a down level profile for those who need it, then it could be removed from standard and more defensive profiles without much fuss. For me, its about acknowledging "one size does not fit all" and managing debates. One size fits all ultimately draws out the process and weakens things even though its not anyone's agenda. >> > Let me put it this way, I see no way for the WG to reasonably agree on >> > this without a proposed _set_ of profiles to go with it that we all >> > could also live with. Just the vague notion of more profiles in >> > abstract isn't sounding great on its own. >> >> We've certainly had a few proposed profiles over time. Your estimation >> of what the WG would or would not agree to is not as interesting as, you >> know, actually attempting to get consensus. > > Agreed, which is why I think this discussion would be more useful with actual > specific profiles to talk about. ;) Right, a concrete list would probably be helpful. The list should probably be based on use cases. * Compatibility - down level servers that can't be upgraded, and clients/UAs that must connect to them * Embedded - low(er) capability crypto, like CAC/PIV cards, smart cards and Hotelier Locks, and similar use cases * Opportunistic - capture email, FTP, etc here. Viktor makes the best arguments here; defer to him * Standard - where the working group would like to be in a typical security posture. * Defensive - where risk adverse folks would like to be in a defensive security posture. Defensive is an interesting profile. I imagine it would include TLS 1.2 and/or 1.3 only, no key transport, authenticated encryption mode ciphers, no HTTPS Pinning Overrides, etc. Then, auditors in industry like healthcare or PCI can call it out by name and everyone is on the same page. The auditors and organizations can worry less about patient or card holder data being leaked because a user was phished or visited another organization (that required a configuration change to use the wireless network). It might also be wise to use "Standard 2015" because in 3 or 5 years, its going to be revised. Then there's no confusion when things are updated an "Standard 2019" becomes available. Jeff _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
