Kathleen Moriarty has entered the following ballot position for draft-ietf-uta-tls-attacks-04: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for your work on this draft! It looks great, but I do have two items I'd like to discuss and see if we can add text to address these concerns/attacks before switching to a yes. 1. I think it would be very helpful to include what techniques are used by forensic tools that enable access to decrypt TLS sessions and how to respond/prevent that access. I see you have certificate attacks listed in 2.7, which is what the common forensic tools leverage. However, these tools also require access to the private key, and it would be helpful to mention the importance of protecting the private key, preventing exportability, etc.. In 2.7 I thin it would be helpful to explicitly state that commonly used forensic tools such as wireshark require access to the private key as well as use of RSA. Another option might be to add the recommendation to protect the private key in 2.13. If you can't export the key (from an implementation perspective), that could go a long way to helping to reduce this method of exposure. I've included a few links for additional information on the list of tools and explicit details of the attack used in case this is helpful. Forensic tools that rely on a MiTM attack to decrypt TLS and DTLS session: http://forensicswiki.org/wiki/SSL_forensics Wireshark requires you have the key: http://support.citrix.com/article/CTX116557 Mitigations are to protect the private key and to not use RSA: http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/ http://wiki.wireshark.org/DTLS?highlight=%28tls%29 If you would like text suggestions, let me know and I'll help. 2. I realize this draft covers explicit attacks against TLS, however since pervasive monitoring is considered an attack, it could be helpful for this draft also cover techniques used by middle boxes to intercept TLS streams (proxy firewalls, load balancers, etc.). Although these are more of 'attacks' on the user, than of TLS, it could be a short addition to have this documented. The TLS session is intercepted, or in the case of a load balancer it might be terminated, with a second TLS session initiated to the destination allowing traffic to pass in the clear on the middlebox. The user is alerted and warned to accept an untrusted certificate in this process, and many do as a result of corporate restrictions (they have no choice if they want to go to that site). Perhaps implementation recommendations could assist here to improve the warnings to the user, letting them know their traffic may be passing in the clear and they may not want to continue with their session. Some may chose to avoid certain transactions from the work place as a result. If you have already discussed these items and decided they were out of scope, please let me know. I support this work and just wanted to make sure we covered all bases or put some out of scope. Thank you. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
