Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

On Fri, Dec 15, 2017 at 9:19 AM, Nikos Mavrogiannopoulos
<nmav@redhat.com> wrote:
> On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck <hanno@hboeck.de> wrote:
>>
>> On Thu, 14 Dec 2017 16:45:57 -0800
>> Colm MacCárthaigh <colm@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