SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
1–10 of 22 posts
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#2The link's not working for me, nor is any reference to SLOTH given on http://www.mitls.org/wsgi/tls-attacks.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#3It's not clear to me that this work establishes that truncated hashes are dangerous, so much as that tls-unique is just not a very good protocol.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#4They mention that tls-unique is used by FIDO. Does this include the U2F specification that is just getting starting to gain acceptance for two-factor authentication? If so, what does it mean for U2F going forward? Are there (potentially/in theory) issues with using it for 2FA?
(I'm not a crypto guy, obviously...)
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#5The link's not working for me, nor is any reference to SLOTH given on http://www.mitls.org/wsgi/tls-attacks .
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#6It's not clear to me that this work establishes that truncated hashes are dangerous, so much as that tls-unique is just not a very good protocol.
I wonder why you're speculating given they used the attacks against default configurations of Java apps, Firefox, some Chrome builds, BouncyCastle, and more. Amusingly, the clients often accepted the weaker crypto even when it was disabled. Fits my meme's nicely. Then, some of the flaws that led to that were fixed.
Not sure how applicable it is now outside a checklist item for a situation that can repeat in a new client. Yet, the paper said they used it on real stuff. Was there something specific you were thinking about that's not covered by that?
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#7More interesting than the attack itself is their overall effort of combining formal verification with protocol implementation. Along the way, they've found all these problems in the other protocols because they didn't use such rigorous methods. Quite an argument in favor of using high assurance techniques for at least critical, slow-changing protocols like TLS.
Anyway, I found this paper...
http://www.ieee-security.org/TC/SP2015/papers-archived/6949a...
...that reminds me of older, high assurance designs. The classic way to do it is the so-called abstract or interacting state machine models. Each component is a state-machine where you know every successful or failure state that can happen plus argument security is maintained. Then, you compose these in a semi-functional way to describe overall system. Seems the miTLS people did something similar for theirs that they call "composite, state machines." The result was clean implementation and verification of what got really messy in other protocol engines. Plus, new techniques for handling that of course.
Really good stuff. Worth extending and improving in new projects.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#8It's not clear to me that this work establishes that truncated hashes are dangerous, so much as that tls-unique is just not a very good protocol.
I wonder why you're speculating given they used the attacks against default configurations of Java apps, Firefox, some Chrome builds, BouncyCastle, and more. Amusingly, the clients often accepted the weaker crypto even when it was disabled. Fits my meme's nicely. Then, some of the flaws that led to that were fixed. Not sure how applicable it is now outside a checklist item for a situation that can repeat in a new cli…
I don't understand your question. I'm not doubting the impact of the paper, just one of its conclusions.
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#9More interesting than the attack itself is their overall effort of combining formal verification with protocol implementation. Along the way, they've found all these problems in the other protocols because they didn't use such rigorous methods. Quite an argument in favor of using high assurance techniques for at least critical, slow-changing protocols like TLS. Anyway, I found this paper... http://www.ieee-security.o…
Formal verification of protocols like TLS is essentially the research thesis behind this group at INRIA, which was also responsible for Logjam (as well as the paper you linked to).
Re: SLOTH – Security Losses from Obsolete and Truncated Transcript Hashes
#10It's not clear to me that this work establishes that truncated hashes are dangerous, so much as that tls-unique is just not a very good protocol.
How would you modify tls-unique to not be vulnerable to collision attacks?