On Sun, October 11, 2015 7:43 pm, Dave Garrett wrote: > I'd like to get a sense of what the WG is willing to consider with regard > to SHA-1, rather than only Viktor and myself discussing this. Basically, I > see 3 options: > > Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully > viable option in TLS 1.3 if nothing better is installed. > Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 > signatures (but may trust full certificates, namely roots). > Option 2: Distrust (option 1) and also prohibit endpoints from sending > chains that rely on SHA-1 signatures to their peers when negotiating TLS > 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your > certificates; self-signed roots still exempt)
My personal preference, speaking on behalf of myself and neither that of my employer or colleagues (we are all individuals here, right? ;D), would be Option 0. If that's all you care to know, stop here - the rest is pontificating and poorly articulating why :) Background: It's no secret I hate SHA-1. I'm accused by a number of Chrome users as being too aggressive in the deprecation of SHA-1. I'm unquestionably accused by CAs of being too harsh on SHA-1 - my opposition towards any extension of SHA-1 signatures by CAs complying with the CA/Browser Forum Baseline Requirements is unquestionable and well known. Why would I support "do nothing"-ism, which is effectively what Option 0 is? Two reasons: - I agree with Viktor that TLS is a protocol for which many credential types can be delivered, and while I have no desire nor intent to support a number of them within Chrome (... I'm looking at you, DANE), I don't deny their utility or viability in some circumstances and environments beyond that of web browsers. It feels inconsistent to apply this to one specific type of credentials, with a particular policy. This is an ideological argument for specification purity, fundamentally, so I fully anticipate disagreement, as is expected with such arguments. - Simply one of complexity. The modern TLS stack, as used in Web browsers (thus revealing my bias, as if we didn't know it already) is already hairy and complex. HTTP/2 imposes a (much needed) profile on ciphersuite negotiations. Browsers themselves key UI off a variety of factors contributing to the connection, both direct (e.g. ciphersuite) and indirect (e.g. mixed content). If we accept that browsers are only concerned with the Web PKI (I know some wish it were otherwise), then the WebPKI is messy, and whether or not a certificate is signed by SHA-1 is... complex and complicated and invokes path building and cross certificates and many of the things outside the remit of TLS. This certificate path building and discovery depends on a variety of factors and external resources (and here's where Martin Rex would chime in about how awful such a state is, but let's accept it as the state of the world today and not argue about necessity or not), and implementing such a policy necessarily interleaves that into the connection management. The 'gross' state of my world today, which will no doubt shock and offend, is that in many cases and ways, the verification of the server identity is deferred until after the overall connection has been established, before any data is transferred over it, and before any keys, session parameters, or overall state is persisted for reuse. The alternative to this is to do something akin to Firefox, which does verification semi-synchronously during handshaking, but which doesn't fetch such external resources (and thus has a much harder time interacting with nominally 'secure' sites), and which if it did, would trigger the various 'retry' logic to deal with servers that time out if the handshakes fail to happen in a 'reasonable' time. Look, I think the deprecation of SHA-1 is a noble goal - hopefully my bonafides are established such that few would want it more - but my concern is that it would add significant implementation complexity to my world, and fundamentally offer no benefit for my existing and documented plans. Were I (and my colleagues) to ignore such a MUST, for entirely pragmatic and yet equally secure reasons, we'd end up cheesing off folks like Dave and those who treat MUSTs as inviolate (reasonably and rightfully so), and would be seen as tacitly encouraging others to ignore such MUSTs as well. I'd like to avoid that world. I think the reasons for such a proposal are laudable, but the pragmatic application and interpretation of such a requirement would be confoundingly obnoxious, and to no obvious benefit, since I (and my counterparts at various other browser organizations) am well on my way to killing SHA-1 within the commercial space. So the only party left to all this is the Enterprise folk, those who will always override a MUST with an application profile, or who will always deal with legacy in such a way that, practically speaking, such a MUST is toothless. Such a requirement doesn't help my efforts towards the death of SHA-1 and evangelizing the need for such a death, and would only distract myself and my colleagues from implementing TLS 1.3 as quickly as reasonable and possible. Maybe it will help in some niche ecosystems that still hold to SHA-1 as the bastion of security, but frankly, may the deity/deities they worship have mercy on their misguided souls. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
