Hubert Kario <hka...@redhat.com> wrote:
>On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote:
>> Hubert Kario <hka...@redhat.com> wrote:
>>>> Thanks to Peter Gutmann for the summary:
>>>> https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs
>>>>
>>>> which you may have missed.
>>>
>>> yes, Joux paper also shows that attacking MD5||SHA1 is harder than
>>> attacking SHA1 alone
>>>
>>> but that doesn't matter, what matters is _how much harder it is_ and Joux
>>> paper says that it's less than a work factor of two, something also knows
>>> as a "rounding error" for cryptographic attacks
>>
>> collision attacks and real-time 2nd preimage attacks on randomly keyed
>> hashes are substantially different things.
>>
>> simple math seems hard.
>>
>>
>> TLSv1.0 + TLSv1.1 both use (rsa, MD5||SHA1)
>>
>> TLSv1.2 (rfc5246) permitted (rsa, MD5) and allows (rsa,SHA1)
>
> side note on that, with ECDSA, all three versions use (ecdsa, sha1) so
> everything we are discussing applies to RSA and RSA only
(EC)DSA is fatally flawed (design flaw), no-one should be using it.
EdDSA once it becomes available, might be OK.
I guess that all existing TLS implementations with ECDSA support might
be leaking (enough info to compute) the ECDSA private key to a mere passive
observer of a few thousand full TLS_ECHDE_ECDSA_ handshakes.
>
> MD5 was deprecated and removed by basically every library
> and can't be used in TLS 1.2, I specifically meant SHA1
MD5 deprecated ? Nope, glaring emtpy:
https://www.rfc-editor.org/errata_search.php?rfc=5246
MD5 removed ? Mostly, but several implementors had to be prodded with
with CVE-2015-7575 (SLOTH) to remove it.
The real issue at hand is:
Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of
interop problems, while at the same time providing *ZERO*
security benefit.
The installed base of software which is limited to TLSv1.0
for outgoing TLS-protected communication is huge.
What *WOULD* provide *HUGE* benefit, would be to remove the
dangerous "protocol version downgrade dance" from careless applications,
that is the actual problem known as POODLE, because this subverts the
cryptographic procection of the TLS handshake protocol.
We've known this downgrade dance to be a problem since the discussion
of what became rfc5746. Prohibiting automatic protoocol version
downgrade dances is going to ensure that two communication peers
that support TLSv1.2 will not negotiate a lower TLS protocol version.
If applications doing downgrade dances had at least a basic amount
of risk management, and would refuse to perform an unlimited amount
of downgrades automatically and secretly, then everyone would be
much better of.
I've seen web browsers doing this entirely without risk management,
and wasn't there some Java class which also did this?
And PLEASE stop unconditionally bashing SHA-1
I am constantly seeing crypto-clueless folks, including some national
governmental agencies, that are giving out their own TLS recommendations,
which are typically sterile of scientific rationale, and it's pretty
obvious those folks either haven't read US NIST SP 800-57 part 1 rev.4
or not understood it. In particular Table 3 on top of page 54, about
the signficant difference between sha1WithRsaEncryption and HMAC-SHA1
e.g. when used for integrity protection by a TLS cipher suites such
as the TLSv1.2 MTI cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.
Security Digital Signatures and HMAC, Key Derivation Functions
Strength hash-only applications Random Number Generation
no <=80 no no no no SHA-1 no no no no no no no no no no no no no no
112 SHA-224,SHA-512/224,SHA3-224
128 SHA-256,SHA-512/256,SHA3-256 SHA-1
192 SHA-384,SHA3-384 SHA-224,SHA-512/224
>=256 SHA-512,SHA3-512 SHA-256,SHA-512/256,SHA-384
SHA-512, SHA3-512
In particular, if you compare HMAC-SHA1 to the shorter&weaker GMAC integrity
protection afforded by AES-GCM cipher suites (rfc5288,rfc5289)
or the even shorter&weaker integrity protection afforded
by AES-CCM cipher suites (rfc6655).
Lots of folks erroneously believe that
TLS_RSA_WITH_AES_128_GCM_SHA256
and more so
TLS_RSA_WITH_AES_256_GCM_SHA384
would provider stronger integrity protection than
TLS_RSA_WITH_AES_128_CBC_SHA
while in reality, it is just the opposite.
-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
