Fundamentally, it is up to the client (or server when doing Client Authentication) to choose whether or not to trust a received certificate chain. I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker message digests), but “I’m not sure it’s a good idea” (SM) to force the issue in a new version of the protocol that is dependent on external specs (e.g. X.509) which permit those message digests. If we want to promote TLSv1.3 and attempt to have faster adoption than TLSv1.2, we can’t shoot ourselves in the foot and not work with a large majority of servers out there still using old certificates. Which by the way, do expire, and subsequently upon renewal, are signed with stronger message digests. The issue is with the old, ancient roots, that still use legacy message digest algorithms, and are less easy to update. But it can be done! I think the onus is really on the library authors to validate the chain, but report anomalies such as SHA-1 in the chain, or a MD5-self-signed-root. The applications are then free to accept the chain or not. Chrome has already done this, and adding support to libraries to make this the default or easier to detect makes it that much easier to deprecate SHA1. In summary, I’m in the SHOULD NOT use SHA-1 camp, rather than the MUST NOT. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet."
On Oct 23, 2015, at 12:33 AM, Viktor Dukhovni <ietf-d...@dukhovni.org<mailto:ietf-d...@dukhovni.org>> wrote: On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote: Most applications want a simple API that hides all the complexities of TLS. If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't cause problems for those apps which said "you take care of it". As someone with a long history of building, influencing, and using libraries and their API's, this is not easy. Binary compatibility is difficult, and requires maintaining legacy versions of interfaces with cross-platform symbol versioning and related magic that transcends the release engineering cycles available to OpenSSL at this time. That said, source compatibility is a fairly reasonable requirement. By and large for applications doing simple things, OpenSSL remains source compatible all the way from 0.9.5a to "master" (soon to be 1.1.0). Postfix, which uses OpenSSL in a rather more sophisticated way, has relatively minor adaptations to deal with source compatibility changes from the 0.9.7 time-frame to the present (we've dropped support for older OpenSSL versions that was present in earlier Postfix releases, otherwise that would be 0.9.5 to the present). Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems for Postfix, it largely continued to work as-is. IIRC the padding extension was needed in 1.0.1g to deal with interoperability with some IronPort systems that had issues with large client HELLO messages solved by padding. The much larger list of ciphersuites also caused pain with some rather dated Microsoft Exchange 2003 servers that were still in use. But on the whole the transition just worked, as it should have. So recompiling a package against an OpenSSL that supports TLS 1.3, and fixing occasional issues with now opaque data structures hidden behind new accessors, should be sufficient for a largely unchanged application to use TLS 1.3 with no explicit code changes to do so. I still want a pony. I expect to report that Postfix works as-is when OpenSSL is released with TLS 1.3. This is not an unreasonable expectation. If TLS 1.3 does not interoperate with opportunistic TLS clients when servers are configured with pre-existing self-signed SHA-1 certificates, then IMHO the specification is broken. If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a CA-issued certificate signed with SHA-1, then OpenSSL is broken, for it should then have worked around the specification brain-damage by selecting TLS 1.2 (presumably the client still supports that). I am perplexed that folks desperately want that server with that SHA-1 cert to not be able to use TLS 1.3. Surely, the decision to not trust that cert (if certs are being checked at all) belongs in the client. Provided that weak self-signatures are not proscribed, I am resigned to "come what may" if nobody else thinks that proper segregation of duties is important, and that putting up some needless roadblocks to TLS 1.3 use is the price of "progress". -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
