[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Fixing TLS
From:       mrex () sap ! com (Martin Rex)
Date:       2016-01-14 14:11:25
Message-ID: 20160114141125.DAE761A3E9 () ld9781 ! wdf ! sap ! corp
[Download RAW message or body]

Ilari Liusvaara wrote:
> Martin Rex wrote:
>> Ilari Liusvaara wrote:
> 
>>> Then there's also similar problems with RSA. And then RSA PKCS #1
>>> v1.5 encryption is on just about every "do not use!" list. Get it
>>> wrong (good luck getting it right) and it is game over.
>> 
>> Getting PKCS#1 v1.5 right is fairly easy, and requiring it should go into
>> TLS 1.2LTS as well.  How to do it right for signatures has been
>> described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already,
> 
> I was talking about encryption, not signatures. Those are used by
> TLS_RSA_WITH_* ciphersuites. The encrpytion is very broken, the
> signatures are at most slightly such.

Encryption is a public key operation.

Maybe you're thinking of *de*cryption instead (aka Bleichenbacher)?
AFAIK, the Bleichenbacher countermeasure uses the fact that RSA
is homomorphic to multiplication.  Decoding the PKCS#1 v1.2 Blocktype 02
padding of the decrypted RSA premaster secret in constant time does
also not require rocket science.  But it seems sufficiently non-obvious
that example code might help.


> 
> (And those lists of crypto algorithms don't list RSA PKCS #1 v1.5
> signatures the same as encryption).
> 
>>>>    - promise to support a certain small subset of EC curves
>>>>      and uncompressed point format whenever ClientHello includes
>>>>      ECDHE cipher suites (but may omit TLS extensions).
>>> 
>>> You have EC formats extension already.
>> 
>> rfc4492 is severly broken, in that it specifies that a ClientHello
>> without the two TLS EC extensions indicates that the client supports
>> *EVERYTHING* in the rfc4492 spec (rather than a reasonable default
>> subset).  I hope that the IESG does not let such obvious breakage
>> enter the standards track.
> 
> Does RFC4492bis fix that?

rfc4492bis can not fix that, unless a new signal is added that clients
can include in ClientHello and that enables servers to distinguish
rfc4492 peers from rfc4492bis peers.


-Martin


[prev in list] [next in list] [prev in thread] [next in thread]