Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

From: [email-masked] (Martin Rex)
Date: Sat, 3 Aug 2019 00:30:14 +0200 (CEST)

Hubert Kario <[email-masked]> wrote:
> On Wednesday, 1 May 2019 01:49:52 CEST Martin Rex wrote:
>> 
>> It is formally provable that from the three protocol versions:
>> 
>>  TLSv1.0, TLSv1.1, TLSv1.2
>> 
>> the weakest one is TLSv1.2, because of the royally stupid downgrade
>> in the strength of digitally signed.
>> 
>> 
>> Disabling TLSv1.0 will only result in lots of interop failures
>> and pain, but no improvement in security.
> 
> We've been over this Martin, the theoretical research shows that for Merkle-
> Damgård functions, combining them doesn't increase their security 
> significantly.
> 
> And the practical research:
> https://eprint.iacr.org/2016/131.pdf
> https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf
> only confirms that.
> 
> So, please, use a bit less inflammatory language when you have no factual 
> arguments behind your assertions.

I recently looked into the practical research paper you referenced,
about what it **REALLY** says.  Maybe you should have read this first,
about the *true* prerequisites of the attack, and what it means *really*
means for the security of digitally_signed using SHA1||MD5 in TLSv1.0+TLSv1.1

From what I can read in that paper, it actually confirms that the security
of digitally_signed using SHA1||MD5 for the TLSv1.0 ServerKeyExchange
handshake message for TLS_ECDHE_RSA_WITH_* is more in the same ballpark
as the security of SHA256, because of the small size of data that gets
signed.

from page 3 of this paper:

   https://eprint.iacr.org/2016/131.pdf

   In this paper, we devise the first second preimage attack on the
   concatenation combiner of Merkle-Damg°ard hash functions which is
   faster than 2^n.  As in related attacks (and in particular, [23])
   we obtain a tradeoff between the complexity of the attack and the
   length of the target message. In particular, our second preimage
   attack is faster than 2^n only for input messages of length at
   least[*2]  2^(2*n/7).  The optimal complexity[*3] of our attack is
   2^(3*n/4), and is obtained for (very) long messages of length 2^(3*n/4).
   Due to these constraints, the practical impact of our second preimage
   attack is limited and its main significance is theoretical.
   Namely, it shows that the concatenation of two Merkle-Damg°ard hash
   functions is not as strong a single ideal hash function.

  [*2]  For example, for n=160 and messge block length 512 bits (as in SHA-1),
        the attack is faster than 2^160 only for messages containing at least
        2^48 blocks, or 2^52 bytes.

  [*3]  The complexity formulas do not take into account (small) constant
        factors, which are generally ignored throughout this paper.

FYI   2^52 bytes == 4,503,599,627,370,496 bytes ==  4 PETA-Bytes

i.e. you need an AWFULLY HUGE amount of "wiggle room" in order to
efficiently construct a multi-collision, and the paper mentions that
if you have just tiny wiggle-room available, you are out-of-luck,
there is no "fast" algorithm for an attack.  More so if you also
have to account for a leading length field in the message.

For comparison size of digitally-signed data in ServerKeyExchange:

      struct {
          select (KeyExchangeAlgorithm) {
              case dh_anon:
                  ServerDHParams params;
              case dhe_dss:
              case dhe_rsa:
                  ServerDHParams params;
                  digitally-signed struct {
                      opaque client_random[32];
                      opaque server_random[32];
                      ServerDHParams params;
                  } signed_params;
              case rsa:
              case dh_dss:
              case dh_rsa:
                  struct {} ;
                 /* message is omitted for rsa, dh_dss, and dh_rsa */
              /* may be extended, e.g., for ECDH -- see [TLSECC] */
          };
      } ServerKeyExchange;

for a DHE-2048 bit keypair, the size of signed data is typically

    32 + 32 + 2 + 256 + 2 + 1 + 2 + 256  = 583 bytes

for ECDHE P-384, the size of signed data is typically

    32 + 32 + 1 + 2 + 1 + 97  = 165 bytes 

So for TLS_ECDHE_RSA_WITH_* cipher suites, you have a *MUCH* stronger
baseline security with TLSv1.0 + TLSv1.1 (SHA1||MD5) than with TLSv1.2
(SHA1-only)

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 3 Aug 2019 02:26:49 +0000

Martin Rex <[email-masked]> / Hubert Kario <[email-masked]> wrote:

[...]

We went through the same thing, in the same thread, with the same people, a
few months ago.  Perhaps we could just replay the messages and everyone else
could sit back and watch?  

And since Hubert has brought up the same bogus argument as last time, perhaps
a good re-read would be in order?  This was already resolved the last time
round.

Peter.