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
