On Wed, Nov 6, 2013 at 2:12 PM, Roberto Peon <grmocg@xxxxxxxxx> wrote:
--
Website: http://hallambaker.com/
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
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/