On Fri, Dec 15, 2017 at 9:19 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck <ha...@hboeck.de> wrote: >> >> On Thu, 14 Dec 2017 16:45:57 -0800 >> Colm MacCárthaigh <c...@allcosts.net> wrote: >> >> > But what would that look like? What would we do now, in advance, to >> > make it easy to turn off AES? For example. >> >> I think this is the wrong way to look at it. >> >> >From what I'm aware nobody is really concerned about the security of >> AES. I don't think that there's any need to prepare for turning off AES. >> >> The problem with PKCS #1 v1.5 is that it survived so long *after* its >> was known that it was bad. I really recommend everyone who wants to >> know how protocols go bad to read up on the Bleichenbacher >> countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last >> one. The chapter in 1.2 is a nightmare and I seriously fail to >> understand how anyone could have seen that and think it's a good idea >> to do that in order to stay compatible with a standard that was already >> deprecated at that point. >> >> We know that when this group decided to deprecate both PKCS #1 1.5 and >> RSA encryption that there were people trying to lobby against that. I'm >> glad that this wasn't successful. > > > RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact > the security of TLS 1.3 is heavily tied to these primitives if servers > support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice > if we can only deprecate RSA PKCS#1 1.5 at some point.
Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS 1.2 and prior? I haven't noticed any discussion on that previously. Is it just the code base and not those using it being unwilling to upgrade supporting libraries? >From RFC8017: To avoid implementation weaknesses related to the way errors are handled within the decoding operation (see [BLEICHENBACHER] and [MANGER]), the encoding and decoding operations for RSAES-OAEP and RSAES-PKCS1-v1_5 are embedded in the specifications of the respective encryption schemes rather than defined in separate specifications. Both encryption schemes are compatible with the corresponding schemes in PKCS #1 v2.1. And, yes, I know deprecation is very hard, but if there's been no effort, it should be considered as TLS 1.2 isn't going away anytime soon. Thanks, Kathleen > > regards, > Nikos > > [0]. https://github.com/tlswg/tls13-spec/pull/1123 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
