Re: [TLS] TLS Charter Revision

[Marsh Ray <[e-mail]>]

From: TLS [mailto:[e-mail]] On Behalf Of Watson Ladd

> I strenuously object to the proposed rechartering as it now stands.
> First, I do not have confidence in this WG and its chair to deliver a secure protocol to the
> IESG. They did not the previous 3 times, and I do not want to give them a 4th shot
> without some guarantee of the quality.

> Secondly, the proposed recharting has made certain technical decisions related to
> the protocol without due discussion, in particular the list of goals implies that we
> keep the stupidity of multiple ciphersuites and extensions galore around.

SSL/TLS has had some issues over the last 20 years, but I can't think of any serious ones *caused* by the multiplicity of ciphersuites and extensions. To the contrary, the version negotiation, cipher suite, and extension mechanisms have been invaluable in rapidly deploying fixes when cracks have appeared in the other parts.

> Thirdly, the experience of TLS 1.2 teaches us that no matter how compatible a
> protocol upgrade is, it will not happen, and so one need not keep compatibility.

That must be why SSLv2 has 99% server market share and TLS has only 20%. Oh wait, I got that backwards. https://www.trustworthyinternet.org/ssl-pulse/
So uhh..."baloney".

Looks like the latest version of Centos and its upstream "major North American Linux vendor"
Made this change "OpenSSL and NSS now support TLS 1.1 and 1.2."
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5

Microsoft clients and servers have supported it for years now but it has been off by default.

Oh looky... 83.9% of sites have even added support for the RFC 5746 Renegotiation Indication security patch in just the last 3-4 years, whereas only 74.3% of servers have disabled SSLv2. I dunno, could have something to do with the fact that the extension mechanism allows adoption without breaking existing clients and servers.

> Fourthly, item 3 is not strong enough: AtE needs to die a fiery death and nothing short of killing RC4 will address its shortcomings.

I agree that AtE was a mistake and needs to go, but what would killing RC4 do to "address its shortcomings"?

> I propose the following charter instead.
> "To create a protocol establishing a secure encrypted and authenticated channel in the
> standard model between parties A and B, supporting the following authentication methods:
> -One-way authentication with the PKI
> -Two-way authentication with the PKI
> -Two-way authentication with a shared low-entropy secret -One side authenticated with the PKI, and the other with a shared low-entropy secret.
> Said protocol will function over UDP and TCP with a minimum of handshakes, complexity, and options, and will have a formal security proof."

Gee you make it sound so easy.

I think we should also consider forward secrecy to be a required and essential security property these days.

Also, how about some security for anonymous connections too? And resistance to traffic analysis and fingerprinting. And privacy of the endpoints' identities. And not becoming a browser evercookie. And not enabling any new forms of server DoS attacks. And so on.

- Marsh