Hi everyone, I second Yaron on the first point: it seems a good idea to mention theft & forensics - in fact, we already reference some of these in the PFS section, so we may as well add a few sentences with overall applicability.
On the second point - I am not quite so sure we should call it an attack. In my experience, there are quite a few companies that use these boxes for entirely legitimate reasons - especially in the context of industrial espionage. When employees are informed and consent to this practice, I do not view it as particularly problematic. In fact, there was a very interesting I-D a while ago that proposed to export the session keys to the middle box automatically so it would not have to break up the cryptographic X.509 link. It did not seem to get much support, unfortunately. My own network measurements show a significant number of certificates that can be identified as having been created by such middle boxes, so they are common. Ralph On 14 October 2014 13:45, Yaron Sheffer <[email protected]> wrote: > Hi Kathleen, > > I sort-of agree with the first point, and fully agree with the second one. > > I think that both theft of the private key and forensic investigation of > the endpoint are essentially out of the document's scope. However, they do > motivate an important decision we made in the BCP: to mandate forward > secrecy. With that in mind, they are worth a mention. > > I agree that a middlebox that inserts itself into the connection by > relying on badly designed UI, a problematic PKI architecture and non-expert > users is indeed a valid attack. Definitely worth a section. > > Thanks, > Yaron > > > > On 10/14/2014 12:19 AM, Kathleen Moriarty wrote: > >> 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 >> >> > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
