On Thursday 23 July 2015 11:43:45 Dave Garrett wrote: > On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote: > > vast swaths of web servers are misconfigured; introducing a more complex > > mechanism to server configuration when the existing situation is > > incomprehensible to many administrators won't help (and even many people > > that write the various blog posts about "how to configure SSL [sic] in > > httpd" clearly haven't read openssl ciphers(1) man page) > > We should just get more serious about banning old crap entirely to make > dangerous misconfiguration impossible for TLS 1.3+ implementations.
there are valid use cases for both aNULL and eNULL at the same time 3.5% of Alexa top 1 million will negotiate AECDH, somehow I doubt this many use it knowingly when ADH has just 0.2% market share TLS is a universal protocol, that means that something that is a dangerous misconfiguration in one threat model is entirely valid and good configuration in other IoT and cloud computing will create a market for an implementation that is compatible with many threat models > Right now, the restrictions section prohibits: > RC4, SSL2/3, & EXPORT/NULL entirely (via min bits) > and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available > > How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all > TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or > ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal > error. (the wrench in this is plain PSK, which should be restricted to > resumption within a short window; IoT people who want to use intentionally > weak security can write their own known weak spec) yes, it would make situation better, thing is, nobody would implement this and nobody would deploy it (certainly not Red Hat). People care more for availability of data than for confidentiality or integrity. > By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be > badly configured to only allow it with DSS, because missing combos from the > cipher suite nonsense happen. If we actually have to care about IE on XP, > we could state an exception that the only non-PFS cipher suite to be > permitted on servers for backwards compatibility is > TLS_RSA_WITH_3DES_EDE_CBC_SHA. and that would prevent the server from never selecting DHE+RSA or client aborting the connection when server selects DHE+RSA how exactly? > Also add a requirement that all config provided by the admin must be > validated to meet the TLS 1.3 requirements and auto-corrected if not, with > a warning if there's an issue. > > This doesn't have to be a mess for admins to sort out. but it is, and for histerical reasons it will remain like this so given choice I prefer my mess to be at least consistent between versions -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls