According to the CA/Browser Forum Baseline Requirements <https://cabforum.org/baseline-requirements-documents/> after 1 January 2016 CAs MUST NOT issue any new Subscriber or Subordinate CA certificates using SHA-1, so we shouldn't see any new certificates with SHA-1 after this date.
Another thing is cost of SHA-1 collision attacks - currently it's at $100K level (see the Freestart collision on full SHA-1 <https://eprint.iacr.org/2015/967> paper), so I think it's pretty much the time when we should say that SHA-1 MUST NOT be used in upcoming TLS versions. On Fri, Oct 23, 2015 at 3:55 PM, Short, Todd <tsh...@akamai.com> wrote: > 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 > // "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> > 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 > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Pozdrawiam | Best Regards Michał Staruch | Information Security Officer ul. Sienkiewicza 9, 65-001 Zielona Góra m...@cinkciarz.pl Find us on Bloomberg CKPL <GO> [image: Cinkciarz.pl Sp. z.o.o] <https://cinkciarz.pl> *Cinkciarz.pl Sp. z o.o.* *Siedziba:* ul. Sienkiewicza 9, 65-001 Zielona Góra *Biuro PL:* Al. Jerozolimskie 123A, 00-965 Warszawa *Biuro UK:* The Broadgate Tower, 20 Primrose Street, London EC2A 2EW *Biuro USA:* 401 North Michigan Avenue, Chicago, Illinois, 60611 *Sekretariat:* +48 726 666 655 | *Infolinia:* +48 68 410 99 50 bi...@cinkciarz.pl | https://cinkciarz.pl KRS 0000364722 | Kapitał zakładowy 23.263.500 zł REGON 080465538 | NIP 9291830388 Audited by: Grant Thornton [image: Oficjalny sponsor Reprezentacji Polski w piłce nożnej] Treść tej wiadomości zawiera informacje poufne, przeznaczone tylko dla adresata. Udostępnianie, ujawnianie, powielanie, rozpowszechnianie bądź powoływanie się na jakikolwiek jej fragment przez inne osoby jest zabronione. W razie przypadkowego otrzymania tej wiadomości prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Informacje zawarte w tej wiadomości mogą być objęte tajemnicą zawodową lub chronione innymi przepisami prawnymi. Nadawca nie bierze odpowiedzialności za jakiekolwiek szkody spowodowane wirusem komputerowym przetransmitowanym w tej wiadomości. Poglądy i opinie przedstawione w tej wiadomości są wyłącznie poglądami i opiniami jej autora i niekoniecznie reprezentują poglądy i opinie firmy. This is a confidential e-mail intended solely for the use of the entity or the individual to whom it is addressed. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. If you have received this message in error please send it back to the sender and delete it. It may also be privileged or otherwise protected by work product immunity or other legal rules. The company accepts no liability for any damage caused by any virus transmitted by this e-mail. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
