Re: [Cfrg] [SSH] [TLS] 3DES diediedie

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Denis,

I concur. 

P.S. On my servers 3DES is prohibited by configuration, but security has (almost) ‎nothing to do with that - rather usage of AES of Suite B and AESNI-accelerated performance (and of course my connecting clients have the same mindset and priorities :).

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: denis bider (Bitvise)
Sent: Thursday, August 25, 2016 18:39
To: Blumenthal, Uri - 0553 - MITLL; Tony Arcieri; Peter Gutmann
Cc: [e-mail]
Subject: Re: [Cfrg] [SSH] [TLS] 3DES diediedie

In SSH, 3des-ctr is currently a cipher in good standing (RFC 4344). CBC is already discouraged (and alerted by many security scanners) because of the issue of naive decryption of packet lengths in this mode.
 
I might be mistaken, but I do not see applicability of this issue in CTR mode. If two ciphertext blocks collide, I don’t see how one could take advantage even if one knows the plaintext corresponding to one of the blocks. If one knows a lot of the plaintext, and therefore finds two key-stream blocks that collide, I’m not seeing what use that could be, either.
 
In addition, SSH has an automatic re-key that is initiated by both clients and servers after every 1 GB of data transferred (128k blocks) in either direction, or every hour, whichever comes first. Most SSH implementations, except rare broken ones that I rarely hear of, either initiate key re-exchange themselves, or support it when it is initiated by the other party. Key re-exchange replaces both encryption keys and the initial IVs in both directions. This also makes attacks against 3des-cbc more difficult.
 
Correct me if I’m wrong, but I don’t see that any action needs to be taken in SSH against 3des-ctr, whereas CBC mode is defended by key re-exchange (with 128k blocks, collision probability less than 1 in 1 billion), and is itself already discouraged.
 
denis
 
 
From: Blumenthal, Uri - 0553 - MITLL
Sent: Thursday, August 25, 2016 09:56
To: Tony Arcieri ; Peter Gutmann
Cc: [e-mail]
Subject: Re: [Cfrg] [TLS] 3DES diediedie
 
>>  An attack that recovers cookie if you can record 785GB of traffic isn't anything I'm losing any sleep over.
>
> ..but is not a terribly dissimilar traffic volume to recover plaintexts from similar attacks against RC4,
> which received "diediedie" in RFC7465.
>
> Perhaps notable is the RC4 attacks work across multiple session keys, whereas SWEET32 requires the same key,
> but I think the practical consequences regarding data volume limits are similar.
 
I think this difference is crucial, because when the majority of the traffic was RC4, then scourging a lot of it and getting at least one key out of the attack seemed bad enough to do something about it. Hence RFC7465.
 
With 3DES, you need that much of traffic protected by the key you’re trying to attack. This completely removes any notion of practicality. I’m not losing my sleep over this either, and think this situation does not justify “diediedie”.
 
_______________________________________________
Cfrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg