[openssl-dev] Proposed cipher changes for post-1.0.2

[Hubert Kario]

On Wednesday 11 February 2015 20:21:37 Viktor Dukhovni wrote:
> On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote:
> > On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
> > > On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:
> > > > I would like to make the following changes in the cipher specs, in the
> > > > master branch, which is planned for the next release after 1.0.2
> > > > 
> > > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> > > 
> > > Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.
> > > 
> > > Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
> > > compatibility issues for opportunistic TLS (e.g. Postfix) where
> > > RC4 is still required for interop and is better than cleartext.
> > 
> > Opportunistic TLS is a-typical use of TLS. One that is vulnerable to
> > trivial MitM attacks by the very definition. Using "ALL", possibly
> > "ALL:!aNULL", instead of "DEFAULT" doesn't make it much less secure.
> 
> Yeah, right, 70-90% of the world's email using opportunistic TLS
> is "atypical".  XMPP server-to-server using opportunistic TLS is
> "atypical", sorry the browser use-case is not the sole use of TLS.

yes, when the encryption is implemented using post-it note with "please don't 
enter" on it it is atypical

especially if you look at the amount of traffic that email and xmpp generate 
compared to HTTP...

I'd like it to be different, but the reality is as it is.
 
> As for vulnerable to MiTM, opportunistic TLS is less vulnerable
> than cleartext. 

yes, point is that as long as you don't do verification of identity of peer 
they are only infinitesimally better from each other.

The library should be "secure by default", you have different need, which is 
"interoperable by default". We can't have both.

> (I'll believe that you actually care that
> opportunistic TLS is not secure enough when Redhat deploys DNSSEC
> and DANE TLSA RRs for its MX hosts).

What I say are not official Redhat statements, I argue arguments, not sides, 
and I don't work in IT so I have minimal impact on what our MXs do.
-- 
Regards,
Hubert Kario