Subject: [saag] Fwd: ubiquitous encryption draft feedback

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Mar 2015 19:03:49 -0400

Forwarding as requested.  Wes has some good comments, Al or I will respond soon.

Thanks,
Kathleen

Sent from my iPhone

Begin forwarded message:

> Resent-From: <[email-masked]>
> From: "George, Wes" <[email-masked]>
> Date: March 11, 2015 at 4:39:58 PM EDT
> Resent-To: <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: ubiquitous encryption draft feedback
> 
> Hi - 
> 
> I think that the section discussing middle boxes decrypting (MiTM) traffic to monitor it (4.2) needs a few bolsters- 
> I'm not sure whether IETF will find the support to actively condemn this behavior (i.e. NOT RECOMMENDED), but a discussion of the considerations around what happens if it's done (or more accurately, done carelessly) would be appropriate for such a document. This is somewhat difficult because it gets into areas that IETF has typically shied away from because it has an intersection between policy, law, and use of technology. However, I still think it's appropriate since IMO first blood was already drawn by wading into the pervasive monitoring debate, which has a similar overlap. 
> 
> Section 4 of the draft makes brief mention of the fact that this might be done outside of the enterprise (e.g. In an SP network) but I would break the link between DLP monitoring and SPs, and instead briefly discuss this in the section on other reasons SPs monitor traffic (in section 2) such as for performance/capacity management or performance optimizations based on the underlying transport media e.g. Improving performance on high-latency and capacity constrained Satellite or mobile connections. The ETSI OWA has covered that set of problems in reasonable detail both in their group and in httpbis when advocating for some sort of provision for decrypting proxies.
> 
> The recent revelations about Gogo inflight, Superfish/Komodia, Comodo and others interfering with the underlying security and trust model of root certificates makes this topical because it provides excellent demonstrations of how this can be done wrong such that it fatally compromises the security the user relies upon, and thus provides an opportunity to highlight the issues one must consider when weighing this option:
> Liability – I realize that IETF does not trade in legal advice, so this would have to be caveated pretty heavily, but I think it's a worthwhile part of the discussion since it's a direct result of a specific set of technical actions and should be weighed when considering whether the ends justify the means.
> Duty to take action – encrypted traffic (or unencrypted traffic that is not subject to DPI) comes with a hidden benefit for the SPs who carry it- plausible deniability. If a service provider or enterprise is decrypting traffic with intent to inspect it, whether with or without its users' knowledge, it can be argued that it is responsible for the traffic's content such that it is required to take action on content or activities that are banned by policy or law, including enforcing copyright, preventing exploitation of children, threats of violence, reporting potential violations to the proper authorities, etc. An SP must be ready to take responsibility for traffic that flows across its network if it chooses to inspect it.
> Duty to protect sensitive information – decrypting middle boxes represent attractive targets since a compromise leads to the potential to access a lot of information that would otherwise be protected by encryption. If a compromise occurs, and it exposes information protected by privacy laws (medical, financial, etc), the SP or enterprise actively making efforts to disable (albeit temporarily) security measures may be held responsible for the damages caused by that information exposure. And the risk isn't limited to traditional bad actors – this makes a good target for state agencies attempting to preserve their pervasive monitoring abilities, thus defeating the purpose of opportunistic/increased encryption in the first place. This problem gets worse if the data is stored unencrypted for any length of time, as it is sensitive to secondary system compromises or government compulsion. There is also the concern about downgrade attacks, where the intermediate device uses weaker ciphers or key lengths when it proxies the connection to the actual destination, thus making the traffic more vulnerable.
> Transparency – this interception and decryption MUST be done with the full knowledge of the users. What this means in execution is something that has been an ongoing debate (i.e. Will normal folks understand a click-through warning well enough to do the "right" thing to protect their information by opting out for sensitive stuff (assuming they're allowed to opt out)? Is it ok to tell employees when they sign their contract but never warn them when you're doing it for sensitive info? etc) but it's definitely worth making that need for transparency crystal-clear, even if we don't necessarily define what is an acceptable level of transparency.
> Feel free to forward this to whatever email list it may be discussed on. It wasn't clear from the draft name where this was headed. 
> Thanks,
>  
> Wes George
>  
> Anything below this line has been added by my company’s mail server, I have no control over it.
> -----------
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Mar 2015 10:38:39 -0400

Hi Wes,

Thanks again for your feedback, it's very helpful.  Responses in line.

On Wed, Mar 11, 2015 at 7:03 PM, Kathleen Moriarty <
[email-masked]> wrote:

> *Resent-From:* <[email-masked]>
> *From:* "George, Wes" <[email-masked]>
> *Date:* March 11, 2015 at 4:39:58 PM EDT
> *Resent-To:* <[email-masked]>
> *To:* "[email-masked]" <
> [email-masked]>
> *Subject:* *ubiquitous encryption draft feedback*
>
> Hi -
>
>  I think that the section discussing middle boxes decrypting (MiTM)
> traffic to monitor it (4.2) needs a few bolsters-
> I'm not sure whether IETF will find the support to actively condemn this
> behavior (i.e. NOT RECOMMENDED), but a discussion of the considerations
> around what happens if it's done (or more accurately, done carelessly)
> would be appropriate for such a document. This is somewhat difficult
> because it gets into areas that IETF has typically shied away from because
> it has an intersection between policy, law, and use of technology. However,
> I still think it's appropriate since IMO first blood was already drawn by
> wading into the pervasive monitoring debate, which has a similar overlap.
>
> We are making an effort to keep this document neutral to encourage
participation and document what is happening, what is the objective, what
data is used, and that it might break with encryption.  Monitoring or
whatever activity is happening may be possible in other ways or it may no
longer be possible, which I think is clear int he draft.  I think the
existing text makes the same point, but keeps this draft away from a policy
document and as more of a helpful document that could be used to figure out
next steps as we better understand the effects of the changes underway.

>  Section 4 of the draft makes brief mention of the fact that this might
> be done outside of the enterprise (e.g. In an SP network) but I would break
> the link between DLP monitoring and SPs, and instead briefly discuss this
> in the section on other reasons SPs monitor traffic (in section 2) such as
> for performance/capacity
>
> I'm confused.  Section 4 is about the effects of monitoring in the
enterprise with increased use of encryption. Do you mean there is some
types of monitoring missing in the sections on encryption and monitoring in
the SP environment?  We could remove the couple of sentences that say the
enterprise might outsource this activity and leave that to the application
content service provider section. I don't think we should be adding text in
this section on the reasons SP monitor traffic.  If we missed some reasons
in section 2, text or pointers to documented information is appreciated.

management or performance optimizations based on the underlying transport
> media e.g. Improving performance on high-latency and capacity constrained
> Satellite or mobile connections. The ETSI OWA has covered that set of
> problems in reasonable detail both in their group and in httpbis when
> advocating for some sort of provision for decrypting proxies.
>
>  The recent revelations about Gogo inflight, Superfish/Komodia, Comodo
> and others interfering with the underlying security and trust model of root
> certificates makes this topical because it provides excellent
> demonstrations of how this can be done wrong such that it fatally
> compromises the security the user relies upon, and thus provides an
> opportunity to highlight the issues one must consider when weighing this
> option:
>
>    - Liability – I realize that IETF does not trade in legal advice, so
>    this would have to be caveated pretty heavily, but I think it's a
>    worthwhile part of the discussion since it's a direct result of a specific
>    set of technical actions and should be weighed when considering whether the
>    ends justify the means.
>
> Hmm, we are trying hard to stay neutral and just document monitoring
practices.  This sounds like another document.  It would be tough in the
IETF as we stay to technical details as much as possible.  The UTA WG
published an RFC on all the attacks against TLS and DTLS as well as a BCP
on configuring TLS and DTLS.

>
>    -
>       - Duty to take action – encrypted traffic (or unencrypted traffic
>       that is not subject to DPI) comes with a hidden benefit for the SPs who
>       carry it- plausible deniability. If a service provider or enterprise is
>       decrypting traffic with intent to inspect it, whether with or without its
>       users' knowledge, it can be argued that it is responsible for the traffic's
>       content such that it is required to take action on content or activities
>       that are banned by policy or law, including enforcing copyright, preventing
>       exploitation of children, threats of violence, reporting potential
>       violations to the proper authorities, etc. An SP must be ready to take
>       responsibility for traffic that flows across its network if it chooses to
>       inspect it.
>
> I think this is more appropriate for privacy statements, or the PM RFC,
but not this one.

>
>    -
>       - Duty to protect sensitive information – decrypting middle boxes
>       represent attractive targets since a compromise leads to the potential to
>       access a lot of information that would otherwise be protected by
>       encryption. If a compromise occurs, and it exposes information protected by
>       privacy laws (medical, financial, etc), the SP or enterprise actively
>       making efforts to disable (albeit temporarily) security measures may be
>       held responsible for the damages caused by that information exposure. And
>       the risk isn't limited to traditional bad actors – this makes a good target
>       for state agencies attempting to preserve their pervasive monitoring
>       abilities, thus defeating the purpose of opportunistic/increased encryption
>       in the first place. This problem gets worse if the data is stored
>       unencrypted for any length of time, as it is sensitive to secondary system
>       compromises or government compulsion. There is also the concern about
>       downgrade attacks, where the intermediate device uses weaker ciphers or key
>       lengths when it proxies the connection to the actual destination, thus
>       making the traffic more vulnerable.
>    - Transparency – this interception and decryption MUST be done with
>    the full knowledge of the users.
>
> We are not arguing for interception and decryption at all in this draft.
Since we are just documenting monitoring practices, I think this belongs in
other drafts as well or scope would be way to big (it's big enough
already).

>
>    - What this means in execution is something that has been an ongoing
>    debate (i.e. Will normal folks understand a click-through warning well
>    enough to do the "right" thing to protect their information by opting out
>    for sensitive stuff (assuming they're allowed to opt out)? Is it ok to tell
>    employees when they sign their contract but never warn them when you're
>    doing it for sensitive info? etc) but it's definitely worth making that
>    need for transparency crystal-clear, even if we don't necessarily define
>    what is an acceptable level of transparency.
>
> This is getting into company policy, which is outside the scope of the
IETF work.

> Feel free to forward this to whatever email list it may be discussed on.
> It wasn't clear from the draft name where this was headed.
>
>
Thanks for your review and detailed response.  If you have monitoring areas
we missed in the SP space, contributions are much appreciated.  If you
think the tone of the draft was not made clear enough, please let us know
what text you think led to that problem and we'll fix it.

Thanks,
Kathleen

> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>
>

-- 

Best regards,
Kathleen

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 26 Mar 2015 17:13:38 -0500

(this was Kathleen forwarding Wes' feedback quoted here)

> Liability – I realize that IETF does not trade in legal advice, so this
> would have to be caveated pretty heavily, but I think it's a worthwhile part
> of the discussion since it's a direct result of a specific set of technical
> actions and should be weighed when considering whether the ends justify the
> means.
>
> Duty to take action – encrypted traffic (or unencrypted traffic that is not
> subject to DPI) comes with a hidden benefit for the SPs who carry it-
> plausible deniability. If a service provider or enterprise is decrypting
> traffic with intent to inspect it, whether with or without its users'
> knowledge, it can be argued that it is responsible for the traffic's content
> such that it is required to take action on content or activities that are
> banned by policy or law, including enforcing copyright, preventing

Heya, as one of the resident policy wonks at IETF I should point out
that the above certainly isn't the case in the US, where
intermediaries generally have broad immunity from liability for
hosting or transmitting third-party content.*

As for the rest of the world, a recent and great UNESCO report by
Rebecca MacKinnon et al. summarizes the landscape by describing three
regimes: strict liability like in China and Thailand where even
ignorance is no excuse, conditional liability where upon receiving
notice the content has to be blocked or the intermediary risks a
lawsuit, etc., and broad immunity such as the case in the US. I'll
stop typing now as I doubt anyone on the SAAG list is as deep into
this stuff as we are at CDT... here's the report, you can start
reading a few pages around PDF p. 40:

http://unesdoc.unesco.org/images/0023/002311/231162e.pdf

All this is saying that I doubt a duty to monitor is a strong argument
here since nothing much exists like that now (and even in the strict
liability cases, which are few, you don't get much by monitoring over
other things like denying access at the onset).

best, Joe

* (Content hosts are required to report instances of child sexual
abuse imagery to the National Center for Missing and Exploited
Children (NCMEC) when they become aware of them, and to retain some
data about the image, but otherwise intermediaries typically don't
have a legal obligation to take action even when they become aware of
potentially unlawful content. The DMCA provides protection from
potential secondary copyright liability -- if the content host takes
down an allegedly infringing file upon notice from a rightsholder, it
can't be sued as having contributed to that infringement. But
technically an intermediary could ignore a DMCA demand and try its
luck in the courts.)

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871