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

[Dave Garrett <[e-mail]>]

On Wednesday, September 16, 2015 07:57:40 pm Jeffrey Walton wrote:
> 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.

What's confusing things here is that SSL3 is _already_ removed from the standards.

RFC 7568 was published to say it MUST NOT be negotiated from any version of TLS:
https://tools.ietf.org/html/rfc7568#section-3

I already added this to the TLS 1.3 draft as well:
https://tools.ietf.org/html/draft-ietf-tls-tls13-08#appendix-C.3

There is no legitimate use of SSL3 by any implementation/organization which acknowledges any new IETF standards. Mention of it at all is a proposal to undo this in some form. It's already supposed to be dead and buried and only in use by obsolete junk which isn't keeping up with new standards.

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

This is certainly true for IoT, in current practice, and that's why there's a separate I-D for that.

> Right, a concrete list would probably be helpful. The list should
> probably be based on use cases.

Yes.

> * Compatibility - down level servers that can't be upgraded, and
> clients/UAs that must connect to them

I argue that this is not a legitimate use case, not because I consider it bogus, per se, but because those in this use-case are already not following standards and thus adding a new one for them is not particularly helpful. There is also no such thing as a server that can't be upgraded; just ones for which someone has decided to not allocate the proper resources to do so because security is not considered a priority.

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

Yes & Yes

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

I'm sort of neutral on this, but it could just be about how we frame it. I'm thinking standard and strict, in that strict simply permits no obsolete features for the purposes of backwards compatibility (e.g. TLS 1.2+ with only features which TLS 1.3 allows). This is somewhat different in that I don't think anything else should change, e.g. recommendations of key strengths or algorithms should not change to accommodate a more defensive posture. The standard should be sufficient on its own. What I'm thinking of is a strict profile that would essentially just be the basis of TLS 1.4's expectations, for those who can do it now, not for any special security need. I'm largely against the idea that we should pick and choose who deserves "good" security and who deserves "ideal" security. Special-casing just lets one group race to the bottom, or stay there.

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

Good point on naming and versioning by year is a very very good idea.


Dave