Subject: [Uta] Kathleen Moriarty's Discuss on draft-ietf-uta-tls-attacks-04: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 13 Oct 2014 14:19:15 -0700

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.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Oct 2014 09:19:59 +0200

> sure we covered all bases or put some out of scope.  Thank you.

Speaking as an individual I am not convinced that the attacks you
describe belong in a draft on TLS attacks since they touch on general
information security principles (private key protection) or are
specific to the PKI trust model (use of wildcard certs in MITM boxes).

I'm not saying that these are not important attacks on TLS, just that
they are not really specific to TLS.

	Cheers Leif

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 14 Oct 2014 14:45:29 +0300

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:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Ralph Holz <[email-masked]>
Date: Tue, 14 Oct 2014 13:59:48 +0200

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-masked]> wrote:

> 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
> relying on badly designed UI, a problematic PKI architecture and non-expert
> users is indeed a valid attack. Definitely worth a section.
>
> Thanks,
>         Yaron
>
>
>
>> http://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-
>> traffic-with-wireshark-and-ways-to-prevent-it/

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 14 Oct 2014 15:29:04 +0300

Hi Ralph,

I agree with you about middleboxes being necessary in some enterprise 
cases (I know that others vehemently disagree). I wish the TLS WG was 
receptive to improve the protocol by allowing such boxes to declare 
themselves and participate actively in the protocol 
(https://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01).

But the "right" way to deploy enterprise middleboxes is by provisioning 
their cert into the employees' endpoints, instead of educating them to 
click through security warnings.

Similarly, airport networks often contain such middleboxes, where the 
user (who has no reason to trust them of course) is supposed to Just 
Click Yes.

Thanks,
	Yaron

On 10/14/2014 02:59 PM, Ralph Holz wrote:
> 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-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Kathleen,
>
>     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.
>
>         Please refer to
>         http://www.ietf.org/iesg/__statement/discuss-criteria.__html
>         <http://www.ietf.org/iesg/statement/discuss-criteria.html>
>         http://datatracker.ietf.org/__doc/draft-ietf-uta-tls-__attacks/
>         <http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/>
>
>
>
>         ------------------------------__------------------------------__----------
>         DISCUSS:
>         ------------------------------__------------------------------__----------
>
>         http://forensicswiki.org/wiki/__SSL_forensics
>         <http://forensicswiki.org/wiki/SSL_forensics>
>         http://support.citrix.com/__article/CTX116557
>         <http://support.citrix.com/article/CTX116557>
>         http://wirewatcher.wordpress.__com/2010/07/20/decrypting-ssl-__traffic-with-wireshark-and-__ways-to-prevent-it/
>         <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
>         <http://wiki.wireshark.org/DTLS?highlight=%28tls%29>
>
>         _________________________________________________
>         Uta mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/uta
>         <https://www.ietf.org/mailman/listinfo/uta>
>
>
>     _________________________________________________
>     Uta mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/uta
>     <https://www.ietf.org/mailman/listinfo/uta>
>
>

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 14 Oct 2014 13:39:04 +0100

On 14 October 2014 12:59:48 BST, Ralph Holz <[email-masked]> wrote:

>In my experience, there are quite a few companies that use these boxes for entirely legitimate reasons -

Quite a few nation state attackers that have actually deployed them widely would no doubt argue their use is also legitimate, likely for the prevention of terror, disharmony, and other bogeymen.

Regardless of the intentions behind their use, MITM proxies do subvert the security properties of TLS as designed and deployed, and are thus correctly regarded as an attack in the general sense. I think it should absolutely be described as such.

>especially in the context of industrial espionage.

TLS interception proxies are indeed useful in that context: they present an extraordinarily attractive vector for an attacker, especially when a target has willingly deployed one and expects to see it in normal use.

I contend that they are not as useful for counter-espionage as some may think, especially given the additional threat they pose. Informed, consenting people could instead grant permissions on the endpoints to someone wishing to audit traffic (such as an antivirus utility), and this is the best place to perform scans as presumably legitimate users have legitimate admin rights and this does not affect the design or deployment of TLS.

Also of course in most deployments, both ends have not provided consent, which is worth bearing in mind in some contexts.

Anyone who's deployed one of these TLS interception middleboxes should perhaps take the opportunity to re-examine and test their assumptions about their usefulness, necessity, and their security. I would probably recommend they SHOULD NOT be used - there may be a valid reason in a specific deployment, but the risks should be weighed up and normally I feel this introduces more risk than it eliminates. To the extent it is accepted practice, I feel that is a problem.

- --
/akr

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Oct 2014 15:56:31 +0200

* Alyssa Rowan <[email-masked]> [141014 14:39]:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 

+1.

> Anyone who's deployed one of these TLS interception middleboxes should perhaps take the opportunity to re-examine and test their assumptions about their usefulness, necessity, and their security. I…

The whole discussion is somewhat political - I don't like to go into
that kind of stuff on technical mailing lists; but: it escalated
after 9/11, most of us will agree on that. I'm not just talking
about the US of A. There has been a global policy shift. In central
europe privacy for snailmail and banking was taken for granted e.g.
a century ago by the general populus. And the arguments politicians
and lobbyists constantly bring up are simply bullshit. Successful
police work or counter-intelligence is possible without ANY use of
modern technology. There's literature en mass on that subject. Some
intelligence agencies [0] even declassified their work on these
subjects during - for example - the cold war. The same holds true
for corporate espionage, controlling and so forth. I just do not see
a valid point in subverting security/privacy protocols for the sake
of policy and politics.

But that's just my opinion,
Aaron

[0] - https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications
      (there's acutally a lot more information on that subject out
       there but I'm convinced that you all know how to use google)

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 14 Oct 2014 10:21:56 -0400

On Tue, Oct 14, 2014 at 9:56 AM, Aaron Zauner <[email-masked]> wrote:

> attack.
> > Quite a few nation state attackers that have actually deployed them
> widely would no doubt argue their use is also legitimate, likely for the
> prevention of terror, disharmony, and other bogeymen.
> >
> > Regardless of the intentions behind their use, MITM proxies do subvert
> the security properties of TLS as designed and deployed, and are thus
> correctly regarded as an attack in the general sense. I think it should
> absolutely be described as such.
>
> +1.
>
> >
> > TLS interception proxies are indeed useful in that context: they present
> an extraordinarily attractive vector for an attacker, especially when a
> target has willingly deployed one and expects to see it in normal use.
> >
> > I contend that they are not as useful for counter-espionage as some may
> think, especially given the additional threat they pose. Informed,
> consenting people could instead grant permissions on the endpoints to
> someone wishing to audit traffic (such as an antivirus utility), and this
> is the best place to perform scans as presumably legitimate users have
> legitimate admin rights and this does not affect the design or deployment
> of TLS.
> >
> > Also of course in most deployments, both ends have not provided consent,
> which is worth bearing in mind in some contexts.
> >
> > Anyone who's deployed one of these TLS interception middleboxes should
> perhaps take the opportunity to re-examine and test their assumptions about
> their usefulness, necessity, and their security. I would probably recommend
> they SHOULD NOT be used - there may be a valid reason in a specific
> deployment, but the risks should be weighed up and normally I feel this
> introduces more risk than it eliminates. To the extent it is accepted
> practice, I feel that is a problem.
>

Thanks for the discussion on this (more is welcome, I'm not trying to stop
the flow).  I'm glad to see there is interest to cover the two intercept
methods described in my discuss as well as the discussion on them.  I think
the important part for the middle box example is the warning/notification
to the user in a clear way so they are empowered to make a decision.  Some
corporate environments,  the security staff is more advanced and has taken
the time to outright block some access that would be encrypted (webmail
sites for instance - fine, that's their right to do that to prevent
viruses, etc.), they have also set up rules so that certain connections do
not go through the TLS proxy (financial sites).  Then there are users like
each of us, who know what the errors mean and can chose to not go to a site
if we think our privacy could be impacted in some way.  This doesn't need
to be described in the draft of course and I'm fine with consensus of the
WG, but would just like to see a clear warning to the user as a best
practice, independent of whether or not it is listed as an 'attack'.

Thanks.

> [0] -
> https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications

-- 

Best regards,
Kathleen

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Oct 2014 16:37:23 +0200

Kathleen Moriarty wrote:
> Thanks for the discussion on this (more is welcome, I'm not trying to
> stop the flow).  I'm glad to see there is interest to cover the two
> intercept methods described in my discuss as well as the discussion on
> them.  I think the important part for the middle box example is the
> warning/notification to the user in a clear way so they are empowered to
> make a decision.  Some corporate environments,  the security staff is
> more advanced and has taken the time to outright block some access that
> would be encrypted (webmail sites for instance - fine, that's their
> right to do that to prevent viruses, etc.), they have also set up rules
> so that certain connections do not go through the TLS proxy (financial
> sites).  Then there are users like each of us, who know what the errors
> mean and can chose to not go to a site if we think our privacy could be
> impacted in some way.  This doesn't need to be described in the draft of
> course and I'm fine with consensus of the WG, but would just like to see
> a clear warning to the user as a best practice, independent of whether
> or not it is listed as an 'attack'.  

Yup. I agree.

This is something I do see at customer sites: with middle-boxes deployed
and an automated, centrally managed IT infrastructure most companies
simply deploy a DPI wildcard certificate on client machines. If they are
willing to inspect traffic, that is. Employees usually will not know the
difference, because there is this nice green lock in their browser when
they visit their banking site. I'm looking forward to the deployment of
certificate transparency, not sure how middle boxes will cope with that.
Certainly the TLS-proxy stuff is something I do not agree with.

Aaron

---

From: Leif Johansson <[email-masked]>
Date: Wed, 15 Oct 2014 01:51:16 +0200

> draft-ietf-uta-tls-attacks-04: Discuss

I guess we need to add a POODLE section too now...

.. but quickly before somebody discovers another logo-and-theme-music
attack or we'll never be done with this.

	Cheers Leif