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

[Kathleen Moriarty <[e-mail]>]

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

> * Alyssa Rowan <[e-mail]> [141014 14:39]:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 14 October 2014 12:59:48 BST, Ralph Holz <[e-mail]>
> wrote:
> >
> > >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 -
> >
> > 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.
>
> >
> > >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.
>
> 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.
>

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.

>
> 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)
>



-- 

Best regards,
Kathleen