Hi Chris, thanks for the proposed text. That's always appreciated.
On 7/21/14, 6:46 PM, Chris Newman wrote:
I've reviewed draft-ietf-uta-tls-attacks-01.txt and support its publication. I believe the document would be improved by including CVE numbers for the vulnerabilities in the document. I had volunteered to write text describing the STARTTLS attack. Here's strawman text: --- 2.9 STARTTLS Command Injection Attack (CVE-2011-0411) A number of IETF application protocols have used an application-level command, usually STARTTLS, to upgrade a clear-text connection to use TLS. Multiple implementations of STARTTLS had a flaw where an application-layer input buffer retained commands that were pipelined with the STARTTLS command, such that commands received prior to TLS negotiation are executed after TLS negotiation. This problem is resolved by requiring the application-level command input buffer to be empty before negotiating TLS. Note that this flaw lives in the application layer code and does not impact the TLS protocol directly.
That seems accurate.
Because several independent implementations had the same problem, use of STARTTLS in new IETF protocols is discouraged.
I don't think it's the role of draft-ietf-uta-tls-attacks (which, if approved, would be an Informational RFC) to discourage the use of STARTTLS in new IETF protocols.
(I also don't think that the presence of bugs in implementations necessitates the kind of changes you have recommended here - instead, those bugs need to be fixed.)
--- This attack is a key factor in changing the bias of the application area with respect to use of STARTTLS
Is that "bias" captured in a document that has the consensus of the application area? Furthermore, has the application area discovered how to weigh the no-STARTTLS bias against the port-conservation bias captured in RFC 6335?
IMHO this topic is probably out of scope for the UTA WG, and deserves to be openly aired in the application area so that consensus can be reached there. Until such a consensus is reached, I don't think we can make such a strong statement in any of the UTA documents.
Peter _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
