Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

[Jeffrey Walton <[e-mail]>]

>> 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