Subject: Clarifying Russ's hums

From: Scott Brim <[email-masked]>
Date: Wed, 6 Nov 2013 13:03:39 -0800

In Russ's hums this morning, some had words that were not well defined.
 Here are three that were not clear to me, and what I hummed about:

"Is the IETF willing to respond to pervasive surveillance as an attack?" ->
"respond" is not clear.  Certainly we have to do something in response to
what we now know. Sam is right, whatever we can imagine is probably already
going on. However, what the response is is not agreed on.

"IETF should include encryption even outside of authentication where
practical" -> "where practical" is not defined. I think each WG will know
what to do with this as long as no one tries to claim that the IETF decided
that we MUST have encryption in all cases.

"The IETF should strive for e2e encryption even when there are middleboxes
in the path" -> "middleboxes" is a full spectrum of devices and functions.
Some of them are quite useful. Until it's clear what the scope is, I hummed
no.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Nov 2013 10:47:53 +1300

Hi Scott,

> Some of them are quite useful. Until it's clear what the scope is, I hummed

It seems to me that all three are perfecly clear as aspirational goals,
and that they all include some room for interpretation. It's also true that
some of them may be in immediate conflict with other goals (for example,
a web proxy that is blind to the content might be rather bad at content
filtering). But all that will come out in the detailed analysis of each
issue. Guiding principles really have to skate over many details.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Wed, 6 Nov 2013 13:55:14 -0800

> issue. Guiding principles really have to skate over many details.

Yes but as presented these could be taken as clear policy statements, not
just guiding principles. I thought embarking on clarifying them asap would
be a good idea.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 6 Nov 2013 14:12:54 -0800

At least one of the questions (and probably two of 'em) for which we hummed
was unclear enough that I couldn't interpret it as a policy statement.

In particular: "The IETF should strive for e2e encryption even when there
are middleboxes in the path":
 - encryption with/without privacy?
 - encryption with/without authentication?
 - do authorized/explicit middleboxes count?

This is too ambiguous for me to interpret in any meaningful way :/
-=R

---

From: Arturo Servin <[email-masked]>
Date: Wed, 6 Nov 2013 20:19:24 -0200

Perhaps because I was reading the transcript it were clear to me. Anyhow,
these are high level goals. We need to build the details along the path.

/as

On Wed, Nov 6, 2013 at 8:12 PM, Roberto Peon <[email-masked]> wrote:

> At least one of the questions (and probably two of 'em) for which we
> hummed was unclear enough that I couldn't interpret it as a policy
> statement.
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 6 Nov 2013 14:26:58 -0800

And I realize that encryption without privacy is silly, but...
-=R

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Nov 2013 14:33:08 -0800

> This is too ambiguous for me to interpret in any meaningful way :/

The issue as I see it is not whether the traffic is visible to
intermediaries but whether this is or should be a surprise.

So for example, if I am sending a message as a private individual to Bob I
may have a choice of sending it to his personal address or his employer's
address. Which I choose is going to depend on the context of the
conversation.

If I specify that the email MUST be encrypted, there are no circumstances
in which the email should be visible to:

* The coffee shop I send the message from
* The ISP serving the coffee shop
* Any backbone router in the path.

If I was sending the message from a company mail server, there are cases
where it might be appropriate for the outbound mail path to be observable.
For example 'conversations may be monitored and recorded'.

But there are no circumstances in which the message should be observable
without my explicit knowledge and consent (accepting that exercising my
right to refuse consent might require me to find a new employer).

On the recipient side, whether the message might be intercepted depends on
whether I send it to Bob's personal or employer address. If I am ordering
parts for my MGB from a supplier then of course I want that supplier to be
able to read my mails to them if Bob falls under a bus (or has an axle
stand fail while he is underneath a car).

These are of course obvious exceptions but all to often they get forgotten
when systems are designed. The critical issue for me is 'surprise'. The
user should not be surprised when they discover that their emails were
vulnerable to disclosure (unless there is a lawfully executed court order).

A subtler question is what to do about spam control and anti-virus. I don't
actually consider content analysis to have much value in spam control but I
certainly don't want my employees accepting executable content in email.

One approach would be to have separate keys for 'end to end' and
'end-to-filter' encryption. The strong email address that goes on my linked
in page would allow anyone to send encrypted email to me at my spam filter.
The other strong email address that allows people to bypass the spam filter
would require some sort of affirmative step so that the sender is
whitelisted by the spam filter and email encrypted under the end-to-end key
would be passed.

-- 
Website: http://hallambaker.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Nov 2013 11:33:21 +1300

> This is too ambiguous for me to interpret in any meaningful way :/

I think the word "strive" is the key. According to Merriam-Webster
(where it's shot into the top 10% of lookups for some reason) it means
"to devote serious effort or energy" to something. I don't see that
we need to resolve all the ambiguities before we adopt the goal
of striving for e2e encryption.

Also could you define what you mean by 'privacy'?

   Brian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 22:39:25 +0000

On Nov 6, 2013, at 2:12 PM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:

At least one of the questions (and probably two of 'em) for which we hummed was unclear enough that I couldn't interpret it as a policy statement.

A lot of that was very generic statements that were bound to achieve consensus.

In particular: "The IETF should strive for e2e encryption even when there are middleboxes in the path":
 - encryption with/without privacy?
 - encryption with/without authentication?
 - do authorized/explicit middleboxes count?

In the context of the IETF, that has to mean encryption with authentication and no authorized or explicit middleboxes.

As soon as you have authorized middleboxes (full disclosure, I was a co-author of a TLS proxy draft [1] that got shot down in the TLS WG), you run into the messy question of "authorized by whom?"

If I install Fiddler to analyze https traffic, that's a trusted proxy. If a government agent installs such a proxy on my computer or on my home router, it's still authorized, but not by me. It's hard to create a slot in the protocol to insert an authorized intermediary that only the user would be able to authorize. The browser vendor, the OS vendor, the employer, the ISP, the malware developer and the national government are all likely to authorize such a middlebox.

There is a flip side. By refusing to specify an authorized middlebox for the protocol, we end up with all middleboxes being treated as equal. As an example, TLS proxies have no standing in the protocol - they work by signing a certificate on behalf of the server's domain name. Key pinning ([2]) detects this middlebox and breaks the connection. But there are legitimate proxies, so using a simple heuristic, browsers detect that a proxy exists, and disable the key pinning protection. If there was a way in the protocol for the proxy to identify itself, clients could then apply a policy that determined whether this was the authorized middlebox (corporate firewall) or some other middlebox. As it is, there are only two things that HPKP can prescribe: disconnect when faced with any proxy, or allow when faced with any proxy.

Yoav

[1] http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01
[2] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Nov 2013 17:47:22 -0500

--On Thursday, 07 November, 2013 10:47 +1300 Brian E Carpenter
<[email-masked]> wrote:

> It seems to me that all three are perfecly clear as
> aspirational goals, and that they all include some room for
> interpretation. It's also true that some of them may be in
> immediate conflict with other goals (for example, a web proxy
> that is blind to the content might be rather bad at content
> filtering). But all that will come out in the detailed
> analysis of each issue. Guiding principles really have to
> skate over many details.

Brian,

I thought of it less as (even) aspirational goals than as
theater and, as such, completely appropriate.  As anything
closer to a consensus evaluation, it seemed to have many of the
properties that draft-resnick-on-consensus warns about: hums at
the end of the process that were not clearly motivated except as
a way of confirming and announcing consensus, assessment and
reporting of loudness as if it were a vote, concentrating on the
majority response rather than the issues and reasoning of the
minority, and asking sweeping questions that don't seem to lead
to anything actionable (I assume that a hum associated with the
question "who is in favor of breathing" would yield at least
equal results. at least unless everyone who didn't hum was then
asked to demonstrate their objections by ceasing to do it).

I also assume that, from a policy standpoint, if an IESG decided
to reject every specification, especially those that update
existing protocols because the result isn't optimal from a
security point of view, we've rapidly see either our first
recalls or some rather dramatic reforms.

I think that, after this morning's discussion, what I'd like to
see is the same thing I would have liked to see yesterday, which
is that every specification be evaluated in terms of the
tradeoffs among all of the considerations that bear on it,
including security generally and surveillance-resistance
specifically.  If the plenary discussion and/or the theatrical
qualities of the hums  leads us to get more serious and
effective about that, it would be, IMO, great.

If not, that would be unfortunate, but I hope today's plenary
was intended to start and frame a discussion that will continue,
not end it.

best,
   john

---

From: Roberto Peon <[email-masked]>
Date: Wed, 6 Nov 2013 14:50:26 -0800

On Wed, Nov 6, 2013 at 2:39 PM, Yoav Nir <[email-masked]> wrote:

>
>  On Nov 6, 2013, at 2:12 PM, Roberto Peon <[email-masked]> wrote:
>
>  In the context of the IETF, that has to mean encryption with
> authentication and no authorized or explicit middleboxes.
>
>
Note that from what I've heard in various interactions this week, this is
not well understood.

>  As soon as you have authorized middleboxes (full disclosure, I was a
> co-author of a TLS proxy draft [1] that got shot down in the TLS WG), you
> run into the messy question of "authorized by whom?"
>
>  If I install Fiddler to analyze https traffic, that's a trusted proxy.
> If a government agent installs such a proxy on my computer or on my home
> router, it's still authorized, but not by me. It's hard to create a slot in
> the protocol to insert an authorized intermediary that only the user would
> be able to authorize. The browser vendor, the OS vendor, the employer, the
> ISP, the malware developer and the national government are all likely to
> authorize such a middlebox.
>
>
In my little world I mean that the sender authorizes the recipient, which
would be true of each side of a full-duplex session, but 'authorization' on
its own without further clarification is ambiguous on its own, agreed.

-=R

 There is a flip side. By refusing to specify an authorized middlebox for
> the protocol, we end up with all middleboxes being treated as equal. As an
> example, TLS proxies have no standing in the protocol - they work by
> signing a certificate on behalf of the server's domain name. Key pinning
> ([2]) detects this middlebox and breaks the connection. But there are
> legitimate proxies, so using a simple heuristic, browsers detect that a
> proxy exists, and disable the key pinning protection. If there was a way in
> the protocol for the proxy to identify itself, clients could then apply a
> policy that determined whether this was the authorized middlebox (corporate
> firewall) or some other middlebox. As it is, there are only two things that
> HPKP can prescribe: disconnect when faced with any proxy, or allow when
> faced with any proxy.
>
>  Yoav
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 07 Nov 2013 15:33:50 +0900

> of striving for e2e encryption.

That's fine, as long as it is understood that any PKI, including
DNSSEC, relying on intelligent intermediate entities of CAs, which
may be compromised by NSA, can not be used for the e2e encryption.

						Masataka Ohta