On Mon, Aug 04, 2014 at 09:50:35AM +0200, Leif Johansson wrote: > On 2014-08-01 15:43, Ilari Liusvaara wrote: > > Here are some attacks that don't seem to be covered (maybe because > > these aren't relevant): > > > > - Not properly checking certificates. > > > > - Relying on broken channel binding > > > > - Triple Hanshake > > > > Regarding DTLS, DTLS 1.0 should behave like TLS 1.1 w.r.t. attacks, > > except that RC4 attacks aren't applicable because the whole algorithm > > is disallowed. > > > Can you suggest specific text for these? This helps the WG judge the > merit of your proposal. >
Some quickly written text (I hope I got the references right): I put the broken channel binding together with triple handshake, as those are closely related. Missing or incomplete certificate validation As shown in [MOST-DANGEROUS-CODE], Many non-browser clients either completely omit certificate validation or do incomplete validation (e.g. not validating server hostname or not validating the trust anchor), leading to those clients being vulernable to Man-in-the-Middle attacks. [MOST-DANGEROUS-CODE] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmatikov, "The most dangerous code in the world: validating SSL certificates in non-browser software", In proceedings of ACM CCS '12, pp. 38-49, 2012 Triple Handshake The triple handshake [TRIPLE-HS] enables attacker to cause two TLS connections to share keying material. This enables multitude of attacks, E.g. Man-in-the-Middle, breaking safe renegotiation and breaking channel binding via TLS-EXPORTER [RFC5705] or TLS-UNIQUE [RFC5929]. [TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, to appear , 2014. -Ilari _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
