Peter Saint-Andre <stpeter@xxxxxxxxxx> writes: >Given that we already discuss these matters in Section 7.4, I don't see the >need for additional text. The issue that I pointed out is in section 4.1, "General Guidelines", while what you're referring to is buried in the security considerations right at the end. What's in 4.1 at the moment is wrong (Raccoon is static-ephemeral DH, not ephemeral-ephemeral DH), so I think it needs to be changed. 4.1 refers to 7.3 but not 7.4, so anyone reading the doc who doesn't read into every corner, including the parts buried after the IANA considerations at the end, will get an incorrect idea of what the issues are. Also what 4.1 is in effect saying is "implementations MUST use ECC algorithms" (via SHOULD NOT RSA (key transport), SHOULD NOT DH, SHOULD NOT DHE), and that includes TLS_ECDH_*, not just TLS_ECDHE_* (section 4.1 says, about *_DH_*, "These cipher suites, which have assigned values prefixed by 'TLS_DH_*', have several drawbacks, especially the fact that they do not support forward secrecy", but omits any mention of the equivalent *_ECDH_* which is no better). Since the ECC algorithms are notoriously vulnerable to nonce issues as well as various others (e.g. forgetting to perform validity checks on received values), it's just moving the insecurity from one algorithm over to another. There's no mention in the security considerations of any issues with replacing DHE with ECC algorithms, it's just "badly implemented DH is insecure" but no mention that badly-implemented ECC is also insecure. For example Brumley et al's attack on ECDHE takes advantage of the same not-really-ephemeral nature that Raccoon uses against DHE, but it's never mentioned. Anyone reading the draft would be forgiven for thinking that all you need to do to magically make all security problems go away is switch to ECC (and GCM, the other universal solution to all problems, despite it also having led to endless vulnerabilities around nonce reuse). Peter. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
