Subject: [perpass] mandatory-to-implement vs. more?

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Oct 2013 22:14:18 +0100

Hi,

Steve's mail argues for the current IETF position that
mandatory-to-implement (MTI) is the correct target IETF
specifications.

Some folks (me included to be honest) wonder if the current
situation argues for raising the bar there somewhat on the
basis that MTI security features are frequently turned off
or not sufficiently well tested to be usable. (Pick your
favourite example, mine are usually rfc4744 or Diameter
being run in clear.) And an upshot from that is that that
helps those who want to pervasively monitor everything.

Others argue that that'd be the IETF straying into the
space of policy - all we should do is define how to use
strong security features and make sure the code is there so
they can be turned on and the rest is policy.

I'm sure there are loads more arguments, and I do think
it'd be useful to see those discussed here.

Thanks,
Stephen.

PS: Our -00 privacy BCP doesn't go beyond MTI for now, but
were there consensus for that, I think it'd be good if we
could go further.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 8 Oct 2013 22:23:49 +0000

Moving the bar from MTI to mandatory-to-use (can we overload the acronym
MTU?) goes beyond just questions of policy, and into the questions of how
we build consensus and what the shapes the output of our engineering
process.

Just to take an example I've followed a bit, SIP is relatively successful
IETF protocol. It has some notable security issues. We could have designed
SIP in a way that reduced the ability of middlemen to work themselves into
the path of SIP messages, and thus reduced the potential for eavesdropping
on the sessions that SIP creates - and its usefulness as a tool of
surveillance.

Had we made some of those design decisions, however, it's unclear to me
that SIP would have been such a successful protocol. But we wouldn't have
made those decisions anyway, because the relevant documents would never
have garnered consensus in the working groups. Our consensus process
reflects the aggregate of the requirements of our participants, which come
from many sources: employers, or regulators, or academic interests, or
personal consciences.

If we had designed SIP to be a protocol that didn't meet those
requirements, of course it wouldn't see much deployment. Extensions to SIP
that have leaned in this direction have had little impact on the
protocol's use. That is the purpose of a consensus process, to reflect the
likely implementation and deployment community. Like it or not, the
participants in our consensus process want protocols like SIP to be
modifiable by intermediaries for numerous reasons - and once we open that
door, we have to understand it will be open for all comers.

We could change our process so that it overrides consensus on some of
these crucial points. I think it would be safe to say that we already do
so, in a limited way, as a results of various forms of cross-area review.
As popular protocol go through our process, we levy requirements that are
winked at by document authors and ignored by implementers. There are
however lines here we could cross that would result in nothing but the
severing of IETF work from the reality of deployment. That would not serve
our mission of making the Internet better.

We undoubtedly need to make changes to reflect our new understanding of
the threats facing the Internet. I think this needs to come from the
bottom up, though, not from the top down. I am heartened that our
consensus process has elevated core security mechanisms to
mandatory-to-use level for some recent work, like in RTCWeb. We need to
shed the brightest light we can on these issues, educate the community
about the new risks and the practical countermeasures, and then execute
our consensus process as we always have. In some cases, mandatory-to-use
will be the right choice. In others, it won't.

Jon Peterson
Neustar, Inc.

On 10/8/13 2:14 PM, "Stephen Farrell" <[email-masked]> wrote:

>_______________________________________________
>perpass mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/perpass

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Oct 2013 12:02:27 +1300

> we build consensus and what the shapes the output of our engineering

How about mandatory-to-be-on-by-default and mandatory-to-have-an-off-switch?

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Oct 2013 00:12:43 +0100

Hi Jon,

I think SIP vs. WebRTC could be a fine contrast that could shed
some light on this, though its maybe a bit early in the latter
case. Do you know if anyone's done a comparison between those
two from the security point of view (well, between SIP deployment
and WebRTC plans is probably the best that could be done I guess).

Some more points below...

> we build consensus and what the shapes the output of our engineering

I don't think I agree there. My suggestion was that we discuss
whether or not we may have a new consensus, not a change in how
we determine consenesus. In the event it appeared there was a
new consensus on this list, that'd have to be tested more
broadly before it'd impact on anything.

> IETF protocol. It has some notable security issues. 

Nice understatement;-) IMO that's quite relevant too. SIP could be
at the same time a nice example of a successful insecure protocol
and of a very unsuccessful security protocol. That's a bit pejorative
but I guess you know what I mean.

> We could have designed
> that SIP would have been such a successful protocol. 

Well, that assumes that the SIP-proxy driven aproach that's current was
always going to be necessary. Its clearly necessary now though so
the middlebox aspect is a real issue here (and for HTTP).

> But we wouldn't have
> winked at by document authors and ignored by implementers. 

Yeah, that's a PITA. References to RFC 4744 and RFC 3118 are my least
favourite things to see when reviewing drafts. Both indicate that
people are trying to pretend to do security, and that they're even
doing that badly;-)

That does I think make for an argument for more than MTI - if it
really has to be used for the protocol to operate, then its far
more likely to work and get used and have been properly engineered.

> There are
> bottom up, though, not from the top down. 

Fully agree. And that's what (I think) we're doing here. Seeing what
really is new and what folks want to do about it. But maybe I'm mixed
up, I've no idea what top-down thing you mean to be honest.

> I am heartened that our

That's one possible outcome - to say that more-than-MTI is a valid
choice that can be made on a protocol by protocol basis. And while
that's not described in BCP61, the WebRTC case shows its doable
aleady I guess that's an argument for the status quo. (Which is fine,
the point for now is to see what arguments there are that might
convince folks here that the status quo is or is not ok.)

S.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 8 Oct 2013 21:00:33 -0400

+1

I do run into cases where people are already confused on MTI and think it means MTU on IETF documents.  I've heard it used as a reason not to use a protocol (too complex for users to implement).  In one case, mutual authentication on a peer-to-peer exchange of sensitive information was argued as too much and a non-IETF standard is getting some traction as a result (so is the IETF standard by those who actually evaluated).  I do think it is important to have key features as MTI, then making it very clear what is MTU and what is by policy may be fine.

Many of us will have to worry about customer requirements that will cover a broad range from different governments (these could evolve), those worried about monitoring, and those that don't set forth any requirements.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Tuesday, October 08, 2013 6:24 PM
To: Stephen Farrell; perpass
Subject: Re: [perpass] mandatory-to-implement vs. more?

Moving the bar from MTI to mandatory-to-use (can we overload the acronym
MTU?) goes beyond just questions of policy, and into the questions of how we build consensus and what the shapes the output of our engineering process.

Just to take an example I've followed a bit, SIP is relatively successful IETF protocol. It has some notable security issues. We could have designed SIP in a way that reduced the ability of middlemen to work themselves into the path of SIP messages, and thus reduced the potential for eavesdropping on the sessions that SIP creates - and its usefulness as a tool of surveillance.

Had we made some of those design decisions, however, it's unclear to me that SIP would have been such a successful protocol. But we wouldn't have made those decisions anyway, because the relevant documents would never have garnered consensus in the working groups. Our consensus process reflects the aggregate of the requirements of our participants, which come from many sources: employers, or regulators, or academic interests, or personal consciences.

If we had designed SIP to be a protocol that didn't meet those requirements, of course it wouldn't see much deployment. Extensions to SIP that have leaned in this direction have had little impact on the protocol's use. That is the purpose of a consensus process, to reflect the likely implementation and deployment community. Like it or not, the participants in our consensus process want protocols like SIP to be modifiable by intermediaries for numerous reasons - and once we open that door, we have to understand it will be open for all comers.

We could change our process so that it overrides consensus on some of these crucial points. I think it would be safe to say that we already do so, in a limited way, as a results of various forms of cross-area review.
As popular protocol go through our process, we levy requirements that are winked at by document authors and ignored by implementers. There are however lines here we could cross that would result in nothing but the severing of IETF work from the reality of deployment. That would not serve our mission of making the Internet better.

We undoubtedly need to make changes to reflect our new understanding of the threats facing the Internet. I think this needs to come from the bottom up, though, not from the top down. I am heartened that our consensus process has elevated core security mechanisms to mandatory-to-use level for some recent work, like in RTCWeb. We need to shed the brightest light we can on these issues, educate the community about the new risks and the practical countermeasures, and then execute our consensus process as we always have. In some cases, mandatory-to-use will be the right choice. In others, it won't.

Jon Peterson
Neustar, Inc.

On 10/8/13 2:14 PM, "Stephen Farrell" <[email-masked]> wrote:

>mandatory-to-implement (MTI) is the correct target IETF specifications.
>
>Some folks (me included to be honest) wonder if the current situation 
>argues for raising the bar there somewhat on the basis that MTI 
>security features are frequently turned off or not sufficiently well 
>tested to be usable. (Pick your favourite example, mine are usually 
>rfc4744 or Diameter being run in clear.) And an upshot from that is 
>that that helps those who want to pervasively monitor everything.
>
>Others argue that that'd be the IETF straying into the space of policy 
>- all we should do is define how to use strong security features and 
>make sure the code is there so they can be turned on and the rest is 
>policy.
>
>I'm sure there are loads more arguments, and I do think it'd be useful 
>to see those discussed here.
>
>Thanks,
>Stephen.
>
>PS: Our -00 privacy BCP doesn't go beyond MTI for now, but were there 
>consensus for that, I think it'd be good if we could go further.
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Oct 2013 02:34:00 +0100

On 10/09/2013 02:00 AM, Moriarty, Kathleen wrote:
> +1
> 
> I do run into cases where people are already confused on MTI and
> think it means MTU on IETF documents.  

True, but a different discussion.

> I've heard it used as a reason
> not to use a protocol (too complex for users to implement). 

Users don't implement as I'd use those terms, so I'm not
sure I get what you mean.

> In one
> case, mutual authentication on a peer-to-peer exchange of sensitive
> information was argued as too much and a non-IETF standard is getting
> some traction as a result (so is the IETF standard by those who
> actually evaluated).  I do think it is important to have key features
> as MTI, then making it very clear what is MTU and what is by policy
> may be fine.

Right, that's the status quo. AFAIK it leads to pretty much
all Diameter exchanges being done in clear. Now that we have
a new threat model, is that still considered ok? I think that
is really worth questioning. As Jon said - WebRTC can do it,
the initial SPDY proposals did it, so there's no reason why
most protocols can't do similarly that I can see - what's
different other than intent? I think there are interesting
questions there to explore.

> Many of us will have to worry about customer requirements that will
> cover a broad range from different governments (these could evolve),
> those worried about monitoring, and those that don't set forth any
> requirements.

That's a little ambiguous: I'm not sure if you're saying you
have customers who are concerned that pervasive monitoring might
be happening, or customers who are governemtns that worry that
they can't monitor enough;-)

But either way, the new reality seems to be that we have a
demonstration that a set of governments want to pervasively
monitor everything. And I'm sure there're others also trying
that. And now there'll be a whole new set trying to join that
club. So even the governments that want to monitor everyone
else will I think soon realise that they're better off it they
themselves/their citizens are less easy to monitor.

I'm very simple: this is an attack on the network. If we
treat it that way, and do that well, we might all win.

S.

> 
> Thanks, Kathleen
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Peterson, Jon Sent:
> Tuesday, October 08, 2013 6:24 PM To: Stephen Farrell; perpass 
> Moving the bar from MTI to mandatory-to-use (can we overload the
> acronym MTU?) goes beyond just questions of policy, and into the
> questions of how we build consensus and what the shapes the output of
> our engineering process.
> 
> Just to take an example I've followed a bit, SIP is relatively
> successful IETF protocol. It has some notable security issues. We
> could have designed SIP in a way that reduced the ability of
> middlemen to work themselves into the path of SIP messages, and thus
> reduced the potential for eavesdropping on the sessions that SIP
> creates - and its usefulness as a tool of surveillance.
> 
> Had we made some of those design decisions, however, it's unclear to
> me that SIP would have been such a successful protocol. But we
> wouldn't have made those decisions anyway, because the relevant
> documents would never have garnered consensus in the working groups.
> Our consensus process reflects the aggregate of the requirements of
> our participants, which come from many sources: employers, or
> regulators, or academic interests, or personal consciences.
> 
> requirements, of course it wouldn't see much deployment. Extensions
> to SIP that have leaned in this direction have had little impact on
> the protocol's use. That is the purpose of a consensus process, to
> reflect the likely implementation and deployment community. Like it
> or not, the participants in our consensus process want protocols like
> SIP to be modifiable by intermediaries for numerous reasons - and
> once we open that door, we have to understand it will be open for all
> comers.
> 
> these crucial points. I think it would be safe to say that we already
> do so, in a limited way, as a results of various forms of cross-area
> review. As popular protocol go through our process, we levy
> requirements that are winked at by document authors and ignored by
> implementers. There are however lines here we could cross that would
> result in nothing but the severing of IETF work from the reality of
> deployment. That would not serve our mission of making the Internet
> better.
> 
> We undoubtedly need to make changes to reflect our new understanding
> of the threats facing the Internet. I think this needs to come from
> the bottom up, though, not from the top down. I am heartened that our
> mandatory-to-use level for some recent work, like in RTCWeb. We need
> to shed the brightest light we can on these issues, educate the
> community about the new risks and the practical countermeasures, and
> then execute our consensus process as we always have. In some cases,
> mandatory-to-use will be the right choice. In others, it won't.
> 
> Jon Peterson Neustar, Inc.
> 
>> situation argues for raising the bar there somewhat on the basis
>> that MTI security features are frequently turned off or not
>> sufficiently well tested to be usable. (Pick your favourite
>> example, mine are usually rfc4744 or Diameter being run in clear.)
>> And an upshot from that is that that helps those who want to
>> pervasively monitor everything.
>> 
>> Others argue that that'd be the IETF straying into the space of
>> policy - all we should do is define how to use strong security
>> features and make sure the code is there so they can be turned on
>> and the rest is policy.
>> 
>> I'm sure there are loads more arguments, and I do think it'd be
>> useful to see those discussed here.
>> 
>> Thanks, Stephen.
>> 
>> PS: Our -00 privacy BCP doesn't go beyond MTI for now, but were
>> there consensus for that, I think it'd be good if we could go
>> further.
>> 
>> 
>> _______________________________________________ perpass mailing
>> list [email-masked] 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
> 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 9 Oct 2013 05:50:14 +0000

I'm sure we could put together some instructive parables on the contrast
between SIP and WebRTC, but that would largely be a discussion about the
different market dynamics of browsers and the web versus the more
telecom-centric influences that shaped SIP. Again, a question of which
requirements constituents bring to the table and what points of consensus
we can reach.

And...

>broadly before it'd impact on anything.

I think we could get a consensus that people really should eat broccoli,
but that's a very different matter than whether or not the meal in front
of us at any given moment should have broccoli in it.

We have a consensus that there should be cross-area review for security
today, and we are working towards similar constraints for privacy, but we
need to acknowledge that there is a certain amount of broccoli being
shoved onto random plates that is perhaps not going into people's mouths
today. If we replace the whole meal with broccoli, people will decide to
dine elsewhere.

[snip]
>more likely to work and get used and have been properly engineered.

I think it makes an argument that we need to target our security
requirements on places where they will genuinely impact implementations
and deployments, rather than flooding security anywhere it will fit and
hoping that a rising tide will lift all boats. Our current process is not
however conducive to identifying places where security will be successful.

[snip]
>> In some cases, mandatory-to-use

I don't mean to argue for the status quo, I'm as outraged and scared as
anyone. I just don't want to see us make changes that will ultimately work
against our interests. I'd like to find ways that we can convince the
community to accept confidentiality mechanisms as routine. My concern is
that, as the case of SIP demonstrated, sometimes the success of a protocol
depends on lacking security features in certain places, and if we're here
to engineer successful protocols, broadly mandating the use of features
like confidentiality will necessary limit that success.

There will be places the community will accept security, and others where
they won't. Today, where they find guidance onerous they just ignore it -
if we make distasteful guidance inseparable from our protocols, then they
will just ignore our protocols.

Jon Peterson
Neustar, Inc.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 9 Oct 2013 08:14:19 +0200

hi Brian, all,

> How about mandatory-to-be-on-by-default and mandatory-to-have-an-off-switch?

It doesn't seem to me that going any further is practical; declaring something "mandatory to use" especially in absence of a deployment certification program (and I hope we can agree we don't want to go there) essentially invites people to ignore you,

Mandatory default (beyond MTI) would at the very least have the effect of moving testing "with security" up the priority list during interop testing.

Case in point: IPFIX. SCTP + DTLS is MTI; TCP and UDP transports (each with TLS/DTLS) are optional. The situation is much better now, but at the time when the Proposed Standard revision (RFC 5101) was first undergoing interop testing, doing a compliant open-source implementation pretty much meant trying to hack working DTLS over SCTP into OpenSSL or similar, or worse, rolling your own DTLS from scratch. So the interop testing ran through all the features "insecure", then treated security as an afterthought. At the first one I took part in, we only managed to interop TCP+TLS.

The temporary guidance we gave in this situation (RFC 5153): use SCTP on dedicated or otherwise-secured (e.g. IPsec tunnels) for new installations inside a trusted perimeter, use TCP+TLS for IPFIX on the open Internet until SCTP+DTLS works. Since NetFlow ran over UDP (very convenient especially for mostly-hardware implementations of exporters) and the NetFlow community is used to the myriad ways in which NetFlow over UDP can fail, we defined a UDP (and UDP+DTLS) binding for IPFIX as well.

Now, SCTP has its own problems on the open Internet, and we'll probably end up defining IPFIX over SCTP over UDP+DTLS as an alternate binding to get around the dodgy middleboxes; that's a separate issue. But I do think part of the problem is that we did not specify default-on for security. The result? Most IPFIX I know of runs unsecured on UDP on local network links which are presumed secure since they're inside the perimeter and don't touch the Big Scary Internet, because that's what you get when you take the box out of the box and plug it in.

Making mandatory default security work is difficult in current practice, in that it adds key management to the out-of-box experience, and there is very little if anything that is fun about key management. Moving toward opportunistic encryption here would be a significant improvement: it guarantees less than "doing it right", but much more than nothing, and in a lot of cases nothing is what we have.

Cheers,

Brian

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Oct 2013 11:20:25 +0100

> it'd be useful to see those discussed here.

How about a distinction in compliance? That is, you can say you comply
to RFC xyzw if you implement it, but to say you _securely_ comply, you
have to switch on the MTUFS (mandatory to use for security) and switch
off MTNUFS (mandatory to not use for security) features in the RFC.
Some RFCs could only have a secure compliance mode, of course.

That way, those who argue that the security is too expensive/not
needed for their use case can disable it, but then can't claim that
they're secure (regardless of the name of the RFC :-).

So, in TLS, for example, secure compliance might consist of TLS 1.2 +
AEAD modes only (note: really an example, not an actual proposal).

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 9 Oct 2013 09:28:38 -0400

Hi Stephen,

I'll respond in line to clarify my initial email.

Thanks,
Kathleen
-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 08, 2013 9:34 PM
To: Moriarty, Kathleen; Peterson, Jon; perpass
Subject: Re: [perpass] mandatory-to-implement vs. more?

On 10/09/2013 02:00 AM, Moriarty, Kathleen wrote:
> +1
> 
> I do run into cases where people are already confused on MTI and think 
> it means MTU on IETF documents.

KM> Yes, but if these are more clearly defined, it could help with the problem you are trying to solve.  Non-IETF people (developers and those who use/setup protocols), from my experience, have trouble understanding what MTI means and the scope of it.  Having MTU defined and differentiated clearly could help this group and assist with the problem you are trying to solve.

> not to use a protocol (too complex for users to implement). 

Users don't implement as I'd use those terms, so I'm not sure I get what you mean.

KM> By implement, I mean setup as opposed to develop code, which is where you mean implement.  Using a protocol may not be the same person as the one who set up a connection.  

> as MTI, then making it very clear what is MTU and what is by policy 

Right, that's the status quo. AFAIK it leads to pretty much all Diameter exchanges being done in clear. Now that we have a new threat model, is that still considered ok? I think that is really worth questioning. As Jon said - WebRTC can do it, the initial SPDY proposals did it, so there's no reason why most protocols can't do similarly that I can see - what's different other than intent? I think there are interesting questions there to explore.

KM> In the case of MILE, there was a protocol written outside of the IETF called TAXII, that is very similar to RID.  Some of the initial reasons that the developers of TAXII used to promote it over RID was that their protocol didn't require mutual authentication, it also does not require TLS and can be sent in the clear if security is too much trouble to configure.  This explanation came my way by a few people.  RID also specifies the ability to provide object level security (XML encryption and digital signatures), this was also seen as too much by the TAXII team even though RID has it as MTI, not MTU.  They are promoting the use of many options, which in addition to security problems, will make interoperability difficult.  There is a lot more to this discussion, but I am limiting it to security features and the result - a protocol that did not have the benefit of IETF review and security options is in use for some instead.  Some are using RID, but how this will play out is still TBD as some prefer the security features and I think it is necessary to have them in a protocol that transports sensitive data.  There are other protocols that may be better for some use cases, but that's another discussion as well.

> those worried about monitoring, and those that don't set forth any 

That's a little ambiguous: I'm not sure if you're saying you have customers who are concerned that pervasive monitoring might be happening, or customers who are governemtns that worry that they can't monitor enough;-)

KM> Both - some governments do not want to sue protocols they suspect could be subject to monitoring.  Then we still have to worry about FIPS compliance requirements for the US government.  For the last group who are in the dark, it would be nice to have them using secure protocols without them having to know about it.

But either way, the new reality seems to be that we have a demonstration that a set of governments want to pervasively monitor everything. And I'm sure there're others also trying that. And now there'll be a whole new set trying to join that club. So even the governments that want to monitor everyone else will I think soon realise that they're better off it they themselves/their citizens are less easy to monitor.

I'm very simple: this is an attack on the network. If we treat it that way, and do that well, we might all win.

KM> The current reality for vendors is that we have to have options.  There might be a monitoring prevention set of options or a profile and a profile to meet specific requirements for regulations (industry or government).  In an ideal world, we could just prevent monitoring everywhere (to the best of our knowledge)

S.

> could have designed SIP in a way that reduced the ability of middlemen 
> to work themselves into the path of SIP messages, and thus reduced the 
> potential for eavesdropping on the sessions that SIP creates - and its 
> usefulness as a tool of surveillance.
> 
> requirements, of course it wouldn't see much deployment. Extensions to 
> SIP that have leaned in this direction have had little impact on the 
> protocol's use. That is the purpose of a consensus process, to reflect 
> the likely implementation and deployment community. Like it or not, 
> the participants in our consensus process want protocols like SIP to 
> be modifiable by intermediaries for numerous reasons - and once we 
> open that door, we have to understand it will be open for all comers.
> 
>> features and make sure the code is there so they can be turned on and 
>> the rest is policy.
>>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 Oct 2013 11:55:09 -0400

Ben,

> O...
That's a novel suggestion, a clever way to try to thread the needle!
But, for many, many years we've had trouble getting the broader community to
recognize than not all RFCs are standards. I doubt that the distinction
you suggest would be better understood.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Oct 2013 17:47:22 +0100

> you suggest would be better understood.

It's all about incentives. Why would anyone care right now whether an
RFC is a standard or not? No-one beats them up for complying with
non-standards. Or even failing to comply with standards.

If we are proposing to move into a world where we incentivise people
to care, then we need to actually call out people who fail to follow
the standards - and, as well, who fail to follow the secure standards.

Just as now it is at least reasonably well understood by vendors that
TLS is desirable, because it gets pointed out if it isn't used, we
need to do the same for other secure standards.

Note that TLS for SMTP does not enjoy the same level of security as
TLS for HTTP. Why? I claim it is because it is completely invisible to
users, so there's no incentives for vendors to get it right.

We need to make these things visible (and I don't mean "show a
padlock", btw, I mean the kind of visibility we propose for
Certificate Transparency, namely, if it doesn't work right, you don't
connect).

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 Oct 2013 13:22:20 -0400

Stephen,

Thanks for creating a new thread to discuss this topic. It's a good 
starting point for

an important discussion.

I think MTU (vs. MTI) is a very hard argument to make, for several reasons,
some of which I noted in my response to Dean.

Internet protocols are used in a very, very wide range of contexts, 
e.g., enterprises of various sorts, the IoT, and public environments. In 
principle one ought to make decisions about what security measures to 
deploy and enable based on a perception of threat. Threats differ in 
different contexts. Our current, MTI-based approach to security enables 
responsible parties in each environment to make decisions about what 
security to offer based on perceived threats and tradeoffs, e.g., 
performance, processing overhead, user experience, etc.

I admit that, in my experience, very few parties appear to make such 
decisions in a well thought-out fashion, but they could. Suggesting that 
we can make such decisions for the folks who are ultimately responsible 
for the operation of services in a wide range of contexts strikes me 
hubristic.

We've already made concessions for the Smart Grid context in the case of 
IPsec as MTI for IPv6. To me this suggests that we were persuaded that 
even MTI can be a barrier to adoption and deployment in some contexts. 
Pursuing a single set of MTUstandards for a wide range of contexts seems 
doomed to failure. Generating MTU RFCs for various contexts might be an 
alternative. That would imply MTI protocol standards, augmented with 
BCPs. Is that what you envision?

Evaluating tradeoffs of security and privacy vs. other factors is hard 
when one deals with a wide range of contexts. For example, end user 
devices range from big servers to laptops, to tablets, to smart phones. 
Battery use if a big issue for some of these devices, as is bandwidth. 
Some of the more extreme TFS mechanisms discussed would have adverse 
implications for both. That's an example of why MTU, at the protocol 
spec levelk,
strikes me as a bad idea.

There are a lot of middleboxes in the Internet. I am no fan of them; I'm 
a true believer in the e-t-e model for everything, not just security. 
But middleboxes are a fact of life and they exist because the folks who 
purchase equipment and offer services have found them to be operational 
necessities. Middleboxes provide ways to deal with backward 
compatibility and migration issues, broken implementations from vendors, 
security services for enterprises, network traffic engineering, etc. If 
we argue that security against widespread nation-state surveillance is 
more important than all of these other considerations, I think we risk 
having the IETF be described as out of touch with reality.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 Oct 2013 13:33:29 -0400

Ben,
...
> non-standards. Or even failing to comply with standards.
That does not seem to be uniformly true. Some folks who purchase
equipment have been know to require prospective bidders to
assert that the products being proposed comply with selected RFCs.
> the standards - and, as well, who fail to follow the secure standards.
I think we gave up on  the notion of the IETF packet police a long time
ago, when Jeff Schiller was Sec AD. :-)
> need to do the same for other secure standards.
TLS has been very successful in terms of widespread deployment, and
a lot of web sites mandate its use. But, it is also an example of
a good technology that has often been misunderstood. If I am at home,
making a credit-card purchase, TLS provides me with protection against
the wrong threat. My CC number is at much greater risk of being stolen
once it has arrived (securely) at the server, vs. when it was in transit.
(If I were using WiFi in Starbucks the threat mode would be different.)
The real benefit to me, as a client, is the nominal authentication of 
the web
site offered by use of the underlying PKI. Of course, the browser PKI model
is not so great, but it's better than nothing.
> users, so there's no incentives for vendors to get it right.
My example above suggests another possible reason; I don't perceive
a serious threat against inter-SMTP server hops for the vast majority of 
my e-mail.
> Certificate Transparency, namely, if it doesn't work right, you don't
Ben, please stop pushing CT as the solution for everything; it's become
more than tiresome.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Oct 2013 18:51:51 +0100

> Ben, please stop pushing CT as the solution for everything; it's become

I was not pushing CT in any way! I was pushing for visibility that is
not a padlock, since we know that doesn't work.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 Oct 2013 14:00:19 -0400

Ben,

Sorry if I misinterpreted your comment in this context.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Oct 2013 19:09:49 +0100

> ago, when Jeff Schiller was Sec AD. :-)

Yeah, I don't think that's the answer. I think the answer is more
along the lines of products not taking the attitude that they should
work around everyone's broken crap, but instead that they should take
a hard line.

In short, "be liberal in what you accept" was a terrible idea for
security and its time we dropped it.

> The real benefit to me, as a client, is the nominal authentication of the
> web
> a serious threat against inter-SMTP server hops for the vast majority of my
> e-mail.

But this is exactly the problem: 99% of the time you don't care, so
you argue that we should make it impossible to fix your problem in the
other 1% of cases.

I think the new reality is that you should worry about the 1% of the
time you care and put up with whatever slight hardships it brings for
your 99% case.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 9 Oct 2013 16:55:05 -0400

Well from a SIP perspective we have always had mandatory to implement TLS in
any number of specifications but in practice no one uses it. No one.  No one
cares.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen Farrell
Sent: Tuesday, October 08, 2013 7:13 PM
To: Peterson, Jon; perpass
Subject: Re: [perpass] mandatory-to-implement vs. more?

Hi Jon,

I think SIP vs. WebRTC could be a fine contrast that could shed some light
on this, though its maybe a bit early in the latter case. Do you know if
anyone's done a comparison between those two from the security point of view
(well, between SIP deployment and WebRTC plans is probably the best that
could be done I guess).

On 10/08/2013 11:23 PM, Peterson, Jon wrote:
> acronym
> MTU?) goes beyond just questions of policy, and into the questions of 
> how we build consensus and what the shapes the output of our 
> engineering process.

I don't think I agree there. My suggestion was that we discuss whether or
not we may have a new consensus, not a change in how we determine
consenesus. In the event it appeared there was a new consensus on this list,
that'd have to be tested more broadly before it'd impact on anything.

> successful IETF protocol. It has some notable security issues.

Nice understatement;-) IMO that's quite relevant too. SIP could be at the
same time a nice example of a successful insecure protocol and of a very
unsuccessful security protocol. That's a bit pejorative but I guess you know
what I mean.

> We could have designed
> SIP in a way that reduced the ability of middlemen to work themselves 
> into the path of SIP messages, and thus reduced the potential for 
> eavesdropping on the sessions that SIP creates - and its usefulness as 
> a tool of surveillance.
> 
> me that SIP would have been such a successful protocol.

Well, that assumes that the SIP-proxy driven aproach that's current was
always going to be necessary. Its clearly necessary now though so the
middlebox aspect is a real issue here (and for HTTP).

> But we wouldn't have
> made those decisions anyway, because the relevant documents would 
> never have garnered consensus in the working groups. Our consensus 
> process reflects the aggregate of the requirements of our 
> participants, which come from many sources: employers, or regulators, 
> or academic interests, or personal consciences.
> 
review.
> As popular protocol go through our process, we levy requirements that 
> are winked at by document authors and ignored by implementers.

Yeah, that's a PITA. References to RFC 4744 and RFC 3118 are my least
favourite things to see when reviewing drafts. Both indicate that people are
trying to pretend to do security, and that they're even doing that badly;-)

That does I think make for an argument for more than MTI - if it really has
to be used for the protocol to operate, then its far more likely to work and
get used and have been properly engineered.

> severing of IETF work from the reality of deployment. That would not 
> serve our mission of making the Internet better.
> 
> the bottom up, though, not from the top down.

Fully agree. And that's what (I think) we're doing here. Seeing what really
is new and what folks want to do about it. But maybe I'm mixed up, I've no
idea what top-down thing you mean to be honest.

> mandatory-to-use will be the right choice. In others, it won't.

That's one possible outcome - to say that more-than-MTI is a valid choice
that can be made on a protocol by protocol basis. And while that's not
described in BCP61, the WebRTC case shows its doable aleady I guess that's
an argument for the status quo. (Which is fine, the point for now is to see
what arguments there are that might convince folks here that the status quo
is or is not ok.)

S.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 9 Oct 2013 22:44:00 +0000

For PSTN replacement deployments in effectively private networks, the case
for transport-level security is unconvincing, sure.

To Steve Kent's earlier point, documents that explain why strong security
is a best practice for particular environments would do better than a
blanket assertion that SIP must always use TLS. If the latter statement
were built into RFC3261, it would serve little purpose other than
rendering many implementations non-compliant with RFC3261. A BCP could
however provide the necessary motivation for using TLS in the situations
where it will actually help, and the recent revelations make that case
rather eloquently.

Jon Peterson
Neustar, Inc.

On 10/9/13 1:55 PM, "Richard Shockey" <[email-masked]> wrote:

>really

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Oct 2013 23:59:13 +0100

On 10/09/2013 11:44 PM, Peterson, Jon wrote:
> A BCP could

I'm confused by that a bit - given the GCHQ/Belgacom example, in
which situations would running SIP over TLS never help?

Note that I've not yet argued for MTU at all, so that's a real
question.

S.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 9 Oct 2013 23:21:14 +0000

I suspect your confusion surrounds who exactly would be helped and what
that help would be. All I was saying is that there are deployments whose
operators and implementers don't perceive the need for such help, and that
we're unlikely to persuade them of it. Making TLS MTU for SIP would have
no appreciable impact on those environments.

Jon Peterson
Neustar, Inc.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2013 00:30:38 +0100

On 10/10/2013 12:21 AM, Peterson, Jon wrote:
> operators and implementers don't perceive the need for such help, 

I agree with that.

> and that
> we're unlikely to persuade them of it. 

Ah. I thought you had said that TLS wouldn't actually add value.

But you actually meant it wouldn't be perceived to add value by
those who don't perceive the need I guess, which seems a little
tautological.

> Making TLS MTU for SIP would have

The question is not IMO whether we declare TLS to be MTU for SIP.

For me, the question is: Nobody uses SIP/TLS now. Using SIP/TLS
would add some value. How can we make it more likely they do use
SIP/TLS?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2013 00:31:43 +0100

> any number of specifications but in practice no one uses it. No one.  No one

BTW - thanks Rich - I think saying what really happens is very helpful.
Pretend security is IMO worse and defo much more of a PITA.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2013 00:51:57 +0100

Hi Steve,

> Thanks for creating a new thread to discuss this topic. It's a good

I agree its important.

> some of which I noted in my response to Dean.

Well, MTU vs MTI is not quite what the subject line says, but is
clearly one of the options worth discussing.

> performance, processing overhead, user experience, etc.

All good.

> decisions in a well thought-out fashion, but they could. 

That's the catch though isn't it? They don't, for whatever reason(s)
as seems to be shown by the SIP discussion.

I conclude that that means we're doing something wrong. (Maybe we're
not the only ones doing something wrong, but I do think we contribute
to the problem.)

> Suggesting that

Hmm. But we're happy enough to suggest that URI scheme names
can't contain a ":" and as a more relevant example, we don't have
a problem that web sockets requires a Sec-WebSocket-Key header. So
I don't buy the "we can't do that" argument to be honest.

> even MTI can be a barrier to adoption and deployment in some contexts.

But on the other hand maybe we were wrong there. Not sure myself.

> doomed to failure. 

Perhaps. But I'm not sure what a "single set of MTUstandards" means
to be honest. If we did have consensus for more than MTI then we
could clearly mess up in loads of ways;-)

> Generating MTU RFCs for various contexts might be an

Could be. Defo worth thinking about. Be great if folks had some
suggestions for situations where that might produce a better
outcome than we have today.

> strikes me as a bad idea.

Hm. I don't see why that applies to just this aspect of protocol
development. Sure, crypto involves some more CPU but that's not
that big a deal (far less than having the radio on in a challenged
device) and some round-trips which turns out to be a problem in
unchallenged-envirionments.

> security services for enterprises, network traffic engineering, etc. 

I'm surprised that you're convinced by the existence of bad practice:-)
But yes, middleboxes are there and we can't ignore that.

> If

Equally, if we ignored pervasive monitoring, we'd actaully be out of
touch with reality.

But there are definite trade-offs here. Its entirely true that we can't
improve privacy without affecting other things. One of my conclusions
from recent revelations is that we've not done a good enough job on
privacy so fixing that will involve such trade-offs if we're serious
about it and not just pretending.

S.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 9 Oct 2013 21:59:16 -0400

+1 .. unlikely is a mild word. I would have probably used the words never
persuade them.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Wednesday, October 09, 2013 7:21 PM
To: Stephen Farrell; Richard Shockey; 'perpass'
Subject: Re: [perpass] mandatory-to-implement vs. more?

I suspect your confusion surrounds who exactly would be helped and what that
help would be. All I was saying is that there are deployments whose
operators and implementers don't perceive the need for such help, and that
we're unlikely to persuade them of it. Making TLS MTU for SIP would have no
appreciable impact on those environments.

Jon Peterson
Neustar, Inc.

On 10/9/13 3:59 PM, "Stephen Farrell" <[email-masked]> wrote:

>> however provide the necessary motivation for using TLS in the 
>> situations where it will actually help, and the recent revelations 
>> make that case rather eloquently.
>
>I'm confused by that a bit - given the GCHQ/Belgacom example, in which 
>situations would running SIP over TLS never help?
>

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 9 Oct 2013 20:28:55 -0700

> would add some value. How can we make it more likely they do use

Define "nobody," please. Microsoft Lync uses SIP/TLS by default. That must
be more than "nobody."

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2013 09:41:27 +0100

> Define "nobody," please. Microsoft Lync uses SIP/TLS by default. That must

Apologies. I was going from Rich and Jon's statements which
I guess are more considering telco deployments. But even if
its "almost nobody," the question remains.

S.

---

From: Mike Demmers <[email-masked]>
Date: Thu, 10 Oct 2013 06:25:15 -0700

On Wed, 9 Oct 2013 09:28:38 -0400

> But either way, the new reality seems to be that we have a demonstration that a set of governments want to pervasively monitor everything. And I'm sure there're others also trying that. And now the…

But that is only one of the major problems: The other is that these idiots are trying to turn the internet into a theater of war. They are actively attackng user systems, not just other state actors. I am not sure if they are actually building botnets of user machines to use as weapons, but they may be. At the least they are attacking routers to gain access for surveillance.

NSA has publicly _admitted_ to attacking over 200 systems. By their own definition, those are acts of war. By most of _our_ definitions, they are, at the least, hacking. Why should any of their packets be allowed on the public internet?

> I'm very simple: this is an attack on the network. If we treat it that way, and do that well, we might all win.

I heartily agree and I think this should be treated as such. All the way to the 'nuclear option', if necessary.

The threat is complex and diffuse. But consider, there is another, somewhat similar threat we have been dealing with for many years, the spam and hacker problems - and some of the specific solutions used for this have been effective.

The antispam community has made community blocklists, used to block email - very effective. Now, even whole providers can find thenselves in blocklists if they do not make an honest attempt to rid themselves of spammers. In the early days, I remember the Cyber Promotions era (Sanford Wallace) and that there was one backbone which decided to allow his business on it that was so heavily blocked and null-routed that it was, if not the cause, at least contrbutory to, its demise.

Maybe we need (voluntary) blocklists for routers, and a similar public response. 'Attack other systems, and you may find ALL your space null routed by blocklists, including nominally unrelated public sites'. Like your spy agency recruiting sites, for example.

RFX-xxxx 'Internet routers, gateways, and firewalls MUST make a good faith effort to drop packets from hosts or networks known to be deliberately attacking other hosts or networks, and SHOULD also block other packets controlled by the same entity'.

Including governments.

It would be nice if all routers had a away to use the kind of blocklists commonly used in email programs (in MTAs).

Because of the amount of spam and hacking that comes from Chinese space, I regularly just block ALL their space, unless there is a business or other good reason not to. This is on -small- business systems, of course. But there are a LOT of those. A lot more than there are large Google sized systems - people forget this. 

If I had a good blocklist for NSA space, GHCQ space, and other defense space, right now I would block it all too, for the same reasons. It's just self defense. 

We have one advantage over the bad guys, which, if we can find good ways to use it, will insure we can win: we outnumber them many, many times over. 

Blocklists are effective because many, many systems voluntariy use them. Nobody -mandated- that, but a mechanism was found to make it -easier-.

Yeah, I am a little angry... ;-) I probably shouldn't write stuff to this list after I have been up all night.

-Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Oct 2013 10:00:47 -0400

I think the problem is that many protocols are at the wrong level of
abstraction to mandate use of any security controls.

For example, consider IPSEC which at one time was mandatory to implement in
IPv6 but isn't any more because most protocols use SSL rather than IPSEC in
any case.

Should TLS be mandatory for SMTP? Well probably but what if an
implementation uses IPSEC?

The same problem comes up with SSL and HTTP. We can mandate the use of SSL
but not a mechanism to validate the certs and without that SSL has little
value.

We can mandate the use of DNSSEC but that would be counterproductive at
this point as DNSSEC is still a protocol with real deployment problems and
issues that have to be fixed before it is ready. They might have been
addressed earlier if the people involved were not so confident that
deployment was inevitable, making use mandatory would further discourage
fixing issues such as how clients get access to the DNSSEC signatures so
they can do validation.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 10 Oct 2013 10:36:19 -0400

Correct in virtually all the teleco deployments of SIP it is not used.  Its
generally not used in the hosted PBX systems the teleco's deploy as well aka
Broadsoft though I'm sure you have better information on the status of
current hosted Lync deployments. Certainly some enterprises do actually turn
on the TLS function but the anecdotal evidence is a very very small
percentage. The resistance level at both the service provider and enterprise
level is actually considerable. 

For the telecos 
A. the customer demand is not there.  There may be a Government demand but
that is another question.

B.  it does represent computational costs that under the current environment
is difficult for service providers to justify from a CAPEX perspective

That said the security situation with Intercarrier SIP traffic IS a matter
under serious consideration with the IETF STIR proposition, but the problem
statement is not the security of the RTP traffic it is actually validating
the source of the call session itself.  That is going to get serious
attention since the problem centers on criminal fraud, disruption of public
safety communications and violation of the national do not call lists.
There are certainly areas where SIP security could be improved could be
improved but we are not the protocol police and IMHO any thought of a
Mandatory to Use security level will simply be ignored until the usability
factors are improved. 

Personally I find IETF discussions of Government behavior distasteful.
Frankly we have met the enemy and it is us.  The IETF ended up designing
security protocols that are very very difficult to deploy at scale.  

E-Mail encryption is the obvious problem.  Oh gee I'm really going to turn
that on if it ends up defeating the anti-spam measures.  Good luck with
that.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen Farrell
Sent: Thursday, October 10, 2013 4:41 AM
To: Christian Huitema; 'Peterson, Jon'; 'Richard Shockey'; 'perpass'
Subject: Re: [perpass] mandatory-to-implement vs. more?

On 10/10/2013 04:28 AM, Christian Huitema wrote:
>> For me, the question is: Nobody uses SIP/TLS now. Using SIP/TLS would 
>> add some value. How can we make it more likely they do use SIP/TLS?
> 
> Define "nobody," please. Microsoft Lync uses SIP/TLS by default. That 
> must be more than "nobody."

Apologies. I was going from Rich and Jon's statements which I guess are more
considering telco deployments. But even if its "almost nobody," the question
remains.

S.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 10 Oct 2013 10:51:54 -0400

++1, Rich.

Furthermore, it's fairly clueless.  Anyone seeking
a secure universe isn't going to find it in this one.
Any given instantiation of anything has n to the nth
vulnerabilities waiting to be discovered and exploited
by someone.  Governments are among the lesser of
the threat actors.

Most of the real world has moved to risk management
conceptualizations - as is pretty obvious on this list.
Along those lines, is the new NIST SP800-53 Rev. 4
useful, and shouldn't the discussion be shifted in that
direction?

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 10 Oct 2013 10:52:31 -0400

I suspect the President of Brazil would be very interested in a BCP on
Mandatory to Use TLS for SIP. :-) 

 But the Government of Brazil has the Authority to Act as a protocol police,
the IETF does not. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephen Farrell
Sent: Wednesday, October 09, 2013 6:59 PM
To: Peterson, Jon; Richard Shockey; 'perpass'
Subject: Re: [perpass] mandatory-to-implement vs. more?

Note that I've not yet argued for MTU at all, so that's a real question.

S.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 10 Oct 2013 11:09:07 -0400

Unlikely; at least not without some back
doors.  Brazil is the leading Latin American
nation in the network surveillance business. :-)
--tony

On 10/10/2013 10:52 AM, Richard Shockey wrote:
> Mandatory to Use TLS for SIP.:-)  
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 10 Oct 2013 11:11:04 -0400

Tony .. Always wonderful to hear from you!

The point we clearly agree on is that a productive discussion on this
subject would be the usability and deployability of security protocols. I
there has been a failure it lies there.  

I totally agree the concepts of risk management and ultimately reputation
management are central to mitigating the problems we now see. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tony Rutkowski
Sent: Thursday, October 10, 2013 10:52 AM
To: Richard Shockey; 'Stephen Farrell'; 'Christian Huitema'; 'Peterson,
Jon'; 'perpass'
Subject: Re: [perpass] mandatory-to-implement vs. more?

++1, Rich.

Furthermore, it's fairly clueless.  Anyone seeking a secure universe isn't
going to find it in this one.
Any given instantiation of anything has n to the nth vulnerabilities waiting
to be discovered and exploited by someone.  Governments are among the lesser
of the threat actors.

Most of the real world has moved to risk management conceptualizations - as
is pretty obvious on this list.
Along those lines, is the new NIST SP800-53 Rev. 4 useful, and shouldn't the
discussion be shifted in that direction?

--tony

On 10/10/2013 10:36 AM, Richard Shockey wrote:
> Frankly we have met the enemy and it is us.  The IETF ended up 
> designing security protocols that are very very difficult to deploy at
scale.
>
> E-Mail encryption is the obvious problem.  Oh gee I'm really going to 
> turn that on if it ends up defeating the anti-spam measures.  Good 
> luck with that.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Oct 2013 13:12:35 -0400

Ben,
> work around everyone's broken crap, but instead that they should take
Amen! But, I so rarely see that attitude among vendors.
> security and its time we dropped it.
I have long said the same re security, even when Jon and I served together
on the IAB. But, as I noted in my reply to Stephen Farrell, we have 
middleboxes
that are part of today's (and yesterday's and tomorrow's) reality. They 
are not
a potential impediment, they are real, and they impose some limits on 
what we _can_ do
technically, in addition to what we _might_ do even if we were confident 
that the vast
majority of users want to accept some inconvenience in the name of 
improved privacy.
> you argue that we should make it impossible to fix your problem in the 
I did not make that argument. I did argue that we ought not impose 
degraded user
experiences on 99% of the users, all the time, to enable some users 
(probably much less that 1%)
to have high quality, covert communications.
> time you care and put up with whatever slight hardships it brings for
Not my reality :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Oct 2013 14:49:49 -0400

Stephen,
> clearly one of the options worth discussing.
I thought that was the focus, based on the subject line. Sorry.
> as seems to be shown by the SIP discussion.
In my experience, enterprise IT folks want to deploy a "solution"
that has low capital cost and low cost to maintain, and that is
perceived as 'best practice" relative to their industry. This is
consistent with some of Dean's observations. Being truly effective
against legitimate threats often is not on their checklist :-) .
> not the only ones doing something wrong, but I do think we contribute
I don 't think we're doing anything  wrong; we're makers of standards,
not enforcers of good security practices for every business, academic
institution, service provider, and individual user of the Internet.
> I don't buy the "we can't do that" argument to be honest.
Sorry, but I don't see the analogy. These are MTI examples, and the first
is a technical compatibility issue, right?
> could clearly mess up in loads of ways;-)
By "single set" I mean MTUs that apply to a standard irrespective
of its use context.
> unchallenged-envirionments.
Fair point; tradeoffs are part of every protocol design, not just
security vs. X tradeoffs. I think that we usually have adequate IETF
participation by folks who are well-positioned to analyze _most_ 
protocol design
tradeoffs. However, we have some significant examples where that has not 
been true.
The first DNSSEC design, approved as a set of RFCs, was not workable. We 
had to
try again, and that cost us several years of effort. I am not convinced 
that we
have the right set of folks participating to design sweeping changes 
that _mandate _
use of security mechanisms that are good enough to deal with nation 
state surveillance.
> Equally, if we ignored pervasive monitoring, we'd actaully be out of
For a long time the IETF has offered security mechanisms that can be
used to protect a wide range of users against a broad spectrum of attacks.
We know that use of many of these mechanisms is very minimal in many 
(most?) contexts.
How does that experience justify mandating _use_ of additional, new 
mechanisms?
Let's not assume that the concern over pervasive monitoring that is
triggering our discussions, and which is well-represented on this list, is
necessarily representative of the concerns (priorities) of most users. When
folks stop posting TMI info on Facebook, updating their locations via
social media, and give up many, many other privacy-undermining habits, 
then I'll
be ready to believe that their priorities have shifted.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2013 19:50:39 +0100

> there has been a failure it lies there.  

I think the above is somewhat fair. We have tended to have only
the crap-or-no security version of protocols and the (ideally)
highly-secure version, which makes a good bit of sense in many
ways but perhaps less when one considers pervasive monitoring.

But personally I don't buy that that exaplains everything. We are
still faced with a bunch of cases where we have MTI security in
specs and its just not deployed. For example, there are no user
interface issues between SIP proxies, and deploying TLS just
should not be hard for such server-server interactions - you'd
nearly have to go out of your way as an implementer to make it
hard I think. (Assuming you start implementing it:-) Maybe as
Jon said the need just wasn't perceived for one reason or
another, but I reckon today's new situation might change that
somewhat.

In any case, mandating strong MTI security just hasn't by
itself worked well enough in some cases for whatever reason.

So... what can we change to make it more likely that good
security and privacy features are specified and deployed?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2013 20:09:37 +0100

Hiya,

> I thought that was the focus, based on the subject line. Sorry.

Partly my fault, but I reckon there should be more options than
just an MTI->MTU transition. For example, requiring BCPs as you
suggested, or maybe requiring (some) security be on-by-default
in some cases or lots of other things. I'm hoping to get folks
suggestions and opinions (so please send yours!)

> against legitimate threats often is not on their checklist :-) .

Yup. Veniality does win sometimes;-)

> institution, service provider, and individual user of the Internet.

I disagree. IMO all the snowdonia stuff is very good evidence that
we need to do better. And "enforcer" is not at issue.

> is a technical compatibility issue, right?

And the 2nd. But the 2nd is a case where there's a teeny bit of
crypto baked into websockets so that websockets just doesn't
work without it. But not one to rathole on.

> By "single set" I mean MTUs that apply to a standard irrespective

Ack.

> use of security mechanisms that are good enough to deal with nation

Going back to a mail from Yoav a few weeks ago - we're not trying to
prevent state surveillance, but we would like to make it more
expensive so Yoav isn't on the list of folks that they can afford
to surveil. Assuming we share that description as a goal, (do we?)
what other kind of folks do you think we might need to make progress
on that?

> be ready to believe that their priorities have shifted.

There is a fair point there but dealing with what people do on FB
is not really within the IETF's scope I think. Making it harder for
a few hacked nodes to record everything everyone does is though.
(And if we can do that well, I suspect we'll get a bunch of other
security benefits too.)

And there's also the user-consent issue - regardless of what one
thinks about web site T&C, it is absolutely the case that users
have not given permission for the pervasive monitoring that's
been reported.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Oct 2013 08:24:29 +1300

Phill,

> IPv6 but isn't any more because most protocols use SSL rather than IPSEC in

Please let's be accurate. The reason that IPsec was a MUST in RFC 4294
but became a SHOULD in RFC 6434 was nothing to do with SSL:

  "This document recognizes that there exists a range of device types
   and environments where approaches to security other than IPsec can be
   justified.  For example, special-purpose devices may support only a
   very limited number or type of applications, and an application-
   specific security approach may be sufficient for limited management
   or configuration capabilities.  Alternatively, some devices may run
   on extremely constrained hardware (e.g., sensors) where the full
   IPsec Architecture is not justified."

Also, it was clear from the start that IPsec for IPv6 was MTI, not MTU,
and the downgrade to RTI (recommended to implement) was to allow for low
end devices where the code would never be used anyway.

   Brian

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 10 Oct 2013 15:42:20 -0400

Probably not a shared goal.

State surveillance has been a "mandate" since the
inception of communications - postal, long before
electronic.  Essentially ever nation engages in it.
Most users don't care.  Some welcome it. Few users
will pay the price or accept the contraints to mitigate it.
Even fewer providers will go out of business to avoid
it.  In most instances involving individuals, the State
threat represents a far less a danger than other actors.
The obvious exceptions are industrial espionage and
cyberwarfare.

The paranoid should climb inside a sealed mu-metal
box with a Faraday shield around it and never exit.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 10 Oct 2013 16:46:52 -0400

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, October 10, 2013 2:51 PM
To: Richard Shockey; 'perpass'
Subject: Re: [perpass] mandatory-to-implement vs. more?

On 10/10/2013 04:11 PM, Richard Shockey wrote:
> subject would be the usability and deployability of security 
> protocols. I there has been a failure it lies there.

I think the above is somewhat fair. We have tended to have only the
crap-or-no security version of protocols and the (ideally) highly-secure
version, which makes a good bit of sense in many ways but perhaps less when
one considers pervasive monitoring.

[RS> ]  A very thoughtful point.  Once we looked at the highly-secure
versions of protocols we inadvertently injected complexity and a difficulty
to implement that caused folks to go .. "WTF I just need this to work."  If
I turn off FOO by default will it work? And we know the answer to that. 

But personally I don't buy that that exaplains everything. 

[RS> ]   I'd never suggest it does. Also a lot of people really don't care
or they actually don't mind a certain level of pervasive surveillance if
there is some rational oversight.  Its not just communications protocols.
London has more CCTV cameras per capita than any city on earth.   RFID tags
on cars can track every conceivable movement.  Forget call detail records..
think of the HLR/VLR/HSS  records on mobile devices. We can go on here but
that is fruitless discussion.  

We are still faced with a bunch of cases where we have MTI security in specs
and its just not deployed. For example, there are no user interface issues
between SIP proxies, and deploying TLS just should not be hard for such
server-server interactions - you'd nearly have to go out of your way as an
implementer to make it hard I think. (Assuming you start implementing it:-) 

[RS> ] Or you don't write the checks...Shockey's law "Money is the answer
what is the question.?"  Look when brother Peterson I and countless others
started working on SIP we idealistically thought we could "replace" the
phone networks. We never envisioned SIP would BECOME the phone network.
When I and others worked on 6116 we thought one thing... the result was
"WHAT!!!  You mean this is really a SS7 TCAP replacement?"   Oh well..  the
best laid plans of mice and engineers. 

Maybe as Jon said the need just wasn't perceived for one reason or another,
but I reckon today's new situation might change that somewhat.

In any case, mandating strong MTI security just hasn't by itself worked well
enough in some cases for whatever reason.

So... what can we change to make it more likely that good security and
privacy features are specified and deployed?

[RS> ]  Well one thing is actually start to enforce "running code"
requirements on new security related protocols.  That is an ongoing debate
in the community well worth expanding on.  We've hit the potholes enough
times where usability and deployability were not mandatory considerations in
the protocol design process.  I would argue now that "pretty good security"
might actually be pretty good vs the alternative which is nothing.  

S.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Oct 2013 17:57:24 -0400

Hay,

>>> I...
Can yo be more specific here? I have not examined all of what is being made
public; I do have a day job :-) .
> work without it. But not one to rathole on.
OK, moving on.
> what other kind of folks do you think we might need to make progress
I understand the goal of making life harder for state surveillance.
However, I am not willing (personally) to incur any degraded user 
experience,
premature cell phone battery depletion, etc in order to support this goal.
I suspect, but cannot prove, that most users would express similar feelings.

But, if there are things we can do that are "free" of adverse impacts,
and supportive of the goal you noted, we should consider them.
> (And if we can do that well, I suspect we'll get a bunch of other
I use Gmail for some traffic. If I really cared about the confidentiality
of that traffic, I should choose another provider. How many million
folks make the same decision?

I use the weather channel to check forecasts for my home area, and
for airports en route to destinations, and for vacation and work
trips. I see ads popping up that are a obvious, direct result of
the WC folks having access to cookies from my browser! Somehow
I learned to live with that ;-) .
> have not given permission for the pervasive monitoring that's
Agreed.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Oct 2013 15:47:15 +0100

> management are central to mitigating the problems we now see.

+1.

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 13 Oct 2013 17:35:50 -0400

Hi Steve,

I'd like to challenge your assertions that because Gmail and Facebook have billions of users, the bulk of Internet users do not care about pervasive state surveillance of all or most of their of their Internet communications, and therefore the IETF's attempts at promoting strong security have thus far been sufficient. Privacy is often valued contextually. The fact that a user accepts the trade-offs that Gmail presents (accepting that a private company will scan her emails in exchange for a snappy interface or beneficial network effects) does not mean that the same user is comfortable with pervasive government surveillance that could allow her to be pursued (using police force) under legal standards that are often vague or uncertain for anything she writes in every email she sends. The state's ability to impinge on a wide range of individual freedoms surpasses by far the ability of any single private company to do so. The line between private and public sector data collection has obviously blurred as more and more data is exchanged between the two, but that does not make the two of them equivalent.

For the list: much of this thread's discussion seems to presume that the business considerations behind individual companies' decisions about whether to deploy secure protocols or not are unchanged from what they were four months ago prior to the beginning of the revelations. Yet elsewhere there seems to be a whole lot of hand-wringing going on about how much business is being lost or how nervous various customers are in the wake of the revelations. Can we really assume that no IT managers in charge of enterprise SIP deployments or middlebox-based backwards-compatability solutions are even considering re-evaluating how they balance competing requirements? 

Alissa

On Oct 10, 2013, at 5:57 PM, Stephen Kent <[email-masked]> wrote:

> However, I am not willing (personally) to incur any degraded user experience,

---

From: Ross Schulman <[email-masked]>
Date: Mon, 14 Oct 2013 08:46:56 -0400

Alissa got to writing this email before I did, but I second pretty much
everything she said here. Corporate data collection is not the same as
pervasive government surveillance. Each has their concerns, but they are
separate and the solutions to the two are considerably different.

-Ross

On Sun, Oct 13, 2013 at 5:35 PM, Alissa Cooper <[email-masked]> wrote:

> Hi Steve,
>
> I'd like to challenge your assertions that because Gmail and Facebook have
> billions of users, the bulk of Internet users do not care about pervasive
> state surveillance of all or most of their of their Internet
> communications, and therefore the IETF's attempts at promoting strong
> security have thus far been sufficient. Privacy is often valued
> contextually. The fact that a user accepts the trade-offs that Gmail
> presents (accepting that a private company will scan her emails in exchange
> for a snappy interface or beneficial network effects) does not mean that
> the same user is comfortable with pervasive government surveillance that
> could allow her to be pursued (using police force) under legal standards
> that are often vague or uncertain for anything she writes in every email
> she sends. The state's ability to impinge on a wide range of individual
> freedoms surpasses by far the ability of any single private company to do
> so. The line between private and public sector data collection has
> obviously blurred as more and more data is exchanged between the two, but
> that does not make the two of them equivalent.
>
> For the list: much of this thread's discussion seems to presume that the
> business considerations behind individual companies' decisions about
> whether to deploy secure protocols or not are unchanged from what they were
> four months ago prior to the beginning of the revelations. Yet elsewhere
> there seems to be a whole lot of hand-wringing going on about how much
> business is being lost or how nervous various customers are in the wake of
> the revelations. Can we really assume that no IT managers in charge of
> enterprise SIP deployments or middlebox-based backwards-compatability
> solutions are even considering re-evaluating how they balance competing
> requirements?
>
> Alissa
>

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 14 Oct 2013 08:47:24 -0400

Hi Alissa,

I'd like to challenge your challenge. :-)
The environment here seems much more
complex than you portray.  It is, however,
still all about risk management.

Most users make their choice of provider
and platform based on factors such as:
cost, performance, ease of use, SPAM
and malware reduction, image (i.e.,
account/domain name), mobility,
identity theft mitigation, familiarity,
and social feature sets.  Like credit
card fraud protection, some of those
features require a lot of invasive knowledge.
Fortunately, there are a lot of providers
competing in the marketplace.

A much smaller number of users who
for reason of employment and need to
protect sensitive information, will be
using designated platforms/providers
- frequently implementing their national
government security agency techniques
and practices.

An even smaller set of people who are
engaged in serious criminal and terrorist
activities will employ a variety of security
methods to prevent detection and interception.
Typically, the more dangerous the activity,
the more secure the communications employed.

An even smaller set who are paranoid about
government - which may be context dependent
- will also want to employ a variety of readily
available security methods.

Since the inception of messaging networks,
governments and societies worldwide have
instituted surveillance for all kinds of
essential legitimate purposes - especially
where the potential harm to people is great.
There are few if any exceptions, and some
like Italy purport to be the world's leaders.
Most citizens want that to continue because
the risks of not doing so are great.  What is
perhaps new is the ability for providers
to make use of some of the same technologies
for commercial services of substantial use
by their customers.  Big Data analysis is
growing by leaps and bounds.

So we come full circle back to the subject
of risk management.  You can probably assume
that wherever you are, your message traffic
is being seen by at least a half dozen parties
who are at least extracting meta data along
the way.  In some contexts, it may be more.
Even in 1995, Scott MacNeally urged the
paranoid to "get over it."

So as many have opined, the IETF is a
technical standards body, not an evangelical
organization for socio-political views, and
hopefully will continue to do what it
does well - produce usable protocols - and
leave the implementation choices to others
based on their assessment of the risk.

--tony

On 10/13/2013 5:35 PM, Alissa Cooper wrote:
> On Oct 10, 2013, at 5:57 PM, Stephen Kent<[email-masked]>  wrote:
>
>> >

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Oct 2013 14:00:36 +0100

On 10/14/2013 01:47 PM, Tony Rutkowski wrote:
> the risks of not doing so are great.

If the "that" above refers to pervasive monitoring,
then please provide evidence (but please do so in
another thread, I bet it'll not be conclusive
enough that one mail will be convincing;-)

If you are referring to tracking or surveillance
of a specific set of targets, then a) that's irrelevant
for this list/discussion which is about pervasive
monitoring, and b) see RFC 2804.

As an aside, its also misleading to speak of citizens
here, since most of us are not citizens of the same
country, for all values of country. So while it is
important and relevant that different jurisdictions
put in place policy/political controls on pervasive
monitoring, those are also not relevant for this
list since in general our protocols can be used
across all possible jurisdictional boundaries.

> technical standards body,

Yes we are. And given that pervasive monitoring is
in some ways indistinguishable from other forms of
attack, we should treat those aspects as an attack
and put in place the best technical mitigations we
can.

And as a reminder the question for this thread,
is whether or not going further than MTI would help
with that.

S.

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 14 Oct 2013 09:25:22 -0400

Hi Steve,

> where the potential harm to people is great. 
"Pervasive monitoring" seems an utterly meaningless
term used for political rhetoric/evangelical purposes
that isn't worth pursuing.  That should be a first order
conclusion.

The point was that this is all about risk management.
However, if you or anyone else want to denominate
a religious abstraction as an "attack" - go for it. :-)
It'll be fun to watch.

--tony

---

From: Avri Doria <[email-masked]>
Date: Mon, 14 Oct 2013 09:43:24 -0400

Hi,

> based on their assessment of the risk.

Yes, but in doing so, it should provide the ability for the individual users, whether companies or individuals, to mitigate their risks.  If technical standards do not include a mandatory option (MTI) of privacy protection they are making a political techno-decsion against privacy.  If the Internet cannot be used in a manner that enhances privacy, for those who value privacy, but only maximizes surveillance based security for those who value surveillance, then it looks to me like we are acting evangelically.

We can only maintain the belief that our technology and protocols are neutral if they can be used by people of diverse socio-political views.

So while I can see problems with MTU, I think genuine MTI (and perhaps some MTU) is needed for privacy enhancements at a level that matches the MTIs and MTUs for security.  I technical neutrality requires it.

avri

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Oct 2013 14:43:56 +0100

Hiya,

>> essential legitimate purposes - especially

"all kinds of essential legitimate purposes" simply
begs the question IMO.

> that isn't worth pursuing.  That should be a first order

Personally, I entirely disagree. It is true that we
don't have a worked out threat model for this yet,
but Brian's draft is a start on which I hope we'll
build so that protocol designers, implementers and
those deploying networks and services will have a
useful threat model to use when doing their work.

> The point was that this is all about risk management.

That's agreed. One reason for this list is that we have a
new threat model that we've not considered when designing
protocols. The risk analysis has been changed by
recent revelations IMO. If you disagree, that's fine,
but surprising.

> a religious abstraction as an "attack" - go for it. :-)

I'll take that rhetorical flourish as a lack of
evidence then:-)

And we're going way off topic for this thread, so
please change the subject if you want to continue
on this topic - its not really to do with MTI at
all.

Ta,
S.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 14 Oct 2013 09:57:24 -0400

This is a good discussion.  I do want to add that we should not forget that there are some simple education issues that we have not made enough progress on yet.  How many of you find yourself explaining to small companies (and even some big ones), that they should not be sending your personal data over email?  This seems to happen to me and luckily, I was able to head it off before it happened the last few times.  As we work to bridge gaps, it will take time and we may need to figure out education options as we work to improve security options.

Bets regards,
Kathleen  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Avri Doria
Sent: Monday, October 14, 2013 9:43 AM
To: perpass
Subject: Re: [perpass] mandatory-to-implement vs. more?

Hi,

On 14 Oct 2013, at 08:47, Tony Rutkowski wrote:

> technical standards body, not an evangelical organization for 
> socio-political views, and hopefully will continue to do what it does 
> well - produce usable protocols - and leave the implementation choices 
> to others based on their assessment of the risk.

avri

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 10:33:01 -0400

Alissa,
> I'd like to challenge your assertions that because Gmail and Facebook have billions of users, the bulk of Internet users do not care about pervasive state surveillance of all or most of their of th…
I appreciate your analysis, but I don't necessarily agree with your 
conclusions. The state has a
responsibility to provide for the security of its citizens. To the 
extent that surveillance supports
this goal, it is potentially justified, irrespective of whether every 
citizen agrees with the
methods. Corporate collection of personal data tends to be driven by 
greed, not quite so noble
a goal :-).

I agree that the state has a more powerful capability to collect info 
about Internet users, and
yes, there are no T's & C's to read and agree to (or, more likely ignore 
and agree to). But
that does not mean that we, as developers of Internet standards, are in 
a position to know
whether all users feel that state vs. corporate surveillance is a 
greater personal concern, and
thus warrants mandatory to use (vs. implement) security features.
> For the list: much of this thread's discussion seems to presume that the business considerations behind individual companies' decisions about whether to deploy secure protocols or not are unchanged…
I'll defer to folks with more direct experience with these businesses, 
but I have seen no such
change in perception. The only change I have seen is that enterprises 
makign use of cloud storage
and backup are more concerned about the confidentiality of the data 
stored there, and are considering
offshore alternatives.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 10:43:39 -0400

Avri,
> So while I can see problems with MTU, I think genuine MTI (and perhaps some MTU) is needed for privacy enhancements at a level that matches the MTIs and MTUs for security.  I technical neutrality r…
To first order, we're in agreement, i.e., MTI provides a reasonable 
basis for deploying privacy
measures when users and service providers choose to make use of them. If 
we fail to provide
MTI options, we deprive users and providers of the ability to engage in 
interoperable
security/privacy measures.

The question Stephen raised is whether that's enough. For me, the answer 
is yes, and going
beyond MTI to MTU is pursuing an "evangelical" path that we ought to avoid.

Since you alluded to "some MTU" above, the obvious question is what are 
examples of
MTU mechanisms that you support?

Steve

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 14 Oct 2013 16:52:14 +0200

>I suspect, but cannot prove, that most users would express similar feelings.

We generally regard representative opinion polls conducted by reputable
polling organisations as adequate proof for statements like that and it
is reasonably inexpensive to commission them, so I think you can. The
problem is of course how to structure the interview, how to phrase the
questions, what kind of answers to offer, what information to provide
upfront, and so on.

I imagine, for instance, many people also do not want to incur degraded
user experience due to state surveillance, like being unable to work
jobs that require a security clearance or being put on a "no fly list"
because some automated system detected too many ungood words in messages
they sent or received; or losing their job because their employer went
out of business after losing the corporate espionage game with a foreign
power.

I suspect, if you asked people whether they are willing to give up, say,
10% battery life, or pay 10% more for their batteries, and be protected
against such threats, most would take the deal. In contrast, if you tell
the story from the other side, get 10% more battery and better chances
to stay in business because some NSA guys owe the CEO a favour, well, I
suspect that also sounds appealing to many.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Mon, 14 Oct 2013 15:54:35 +0100

Stephen,

"The state has a  responsibility to provide for the security of its
citizens. To the extent that surveillance supports
this goal, it is potentially justified, irrespective of whether every
citizen agrees with the  methods."

If this is the case why dont we hand a copy of our house key to the police?
This way the police can come around every evening and check what we are up
to.

Why not cameras on toilets as well?

Because mass surveillance (for good and bad) scares the Internet user. It
makes it less attractive to use the Internet. It restricts the Internet. It
violates the Universal Declaration of Human Rights (to which your country
is a signatory as well).

It is not the targeted surveillance but the unregulated mass surveillance
that is the problem.

The current IETF standards do not protect against mass surveillance
sufficiently.

regards,

Ralf

On Mon, Oct 14, 2013 at 3:33 PM, Stephen Kent <[email-masked]> wrote:

> Alissa,
>
>  Hi Steve,
>>
>> I'd like to challenge your assertions that because Gmail and Facebook
>> have billions of users, the bulk of Internet users do not care about
>> pervasive state surveillance of all or most of their of their Internet
>> so. The line between private and public sector data collectio
>>
> n has obviously blurred as more and more data is exchanged between the
> two, but that does not make the two of them equivalent.
> responsibility to provide for the security of its citizens. To the extent
> that surveillance supports
> that does not mean that we, as developers of Internet standards, are in a
> position to know
> whether all users feel that state vs. corporate surveillance is a greater
> personal concern, and
> I'll defer to folks with more direct experience with these businesses, but
> I have seen no such
> and backup are more concerned about the confidentiality of the data stored
> there, and are considering
> offshore alternatives.
>
>
> Steve
>
> ______________________________**_________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Mon, 14 Oct 2013 16:01:16 +0100

Hi,

> I suspect, but cannot prove, that most users would express similar

I remember the same argument from the last decade when the Internet
transitioned from TELNET to SSH. Some people said SSH would cause to much
internet traffic and the servers could not handle the extra crypto.

Imagine today's internet with every admin still using TELNET.

Where are these admins now? Speak up please.

regards,

Ralf

---

From: Avri Doria <[email-masked]>
Date: Mon, 14 Oct 2013 11:05:46 -0400

> Since you alluded to "some MTU" above, the obvious question is what are examples of

I don't know.  But just as I beleive we sometimes decide some things are so critical to security that they must be used, I would like to see us leave open the discussion of whether there may, on occasion, be things that require this.  

They may, for example, be protocol options in servers that unless used, prevent users from optionally using a privacy feature.  But I am not far enough down into the weeds on this issue to have an example at the moment.  I admit that in many occasions MTU is probably more of a policy decision than a technical one, but not always.

avri

On 14 Oct 2013, at 10:43, Stephen Kent wrote:

> To first order, we're in agreement, i.e., MTI provides a reasonable basis for deploying privacy
> measures when users and service providers choose to make use of them. If we fail to provide
> MTI options, we deprive users and providers of the ability to engage in interoperable
> The question Stephen raised is whether that's enough. For me, the answer is yes, and going
> Since you alluded to "some MTU" above, the obvious question is what are examples of

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 11:21:14 -0400

Bjoern,
> questions, what kind of answers to offer, what information to provide
An opinion poll is not necessarily the best way to measure the
relative priority of individuals in matters like this. The behavior
of individuals may be a better measure. (Individuals may want to
say that they are in favor of X or against Y, but their behavior
may not be consistent with their response to a poll.
> suspect that also sounds appealing to many.
Yes, depending on how one asks the questions, contradictory responses
may be elicited.

Steve

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 14 Oct 2013 11:35:43 -0400

Steve,

Brian's draft defines "pervasive surveillance" as
> the practice of
> surveillance at widespread observation points, without any
> modification of network traffic, and without any particular
> surveillance target in mind.
There are a couple of obvious deficiencies here..

As a starter, the definition is self-contradictory.
The first sentence in the introduction uses RFC6973's
definition of surveillance with is aimed at an individual
and concatenates it with "pervasive" to come up with
something that says there "is no particular surveillance
target in  mind."  Which is it?  You cannot logically
concatenate the two notions together.

You also don't deal with timeframes.  Most Big Data
implementations for all kinds of purposes, acquire
observations and sort out the metadata.  That's how
particular particular targets (e.g., purveyors of cheap
nuclear devices) are found, and it's mandated by law
under the E.U. Data Retention Directive.

Additionally, all this is context dependent as there all
kinds of bases for exactly this kind of activity that are
operational, commercial, and legal.  It would also be
interesting to see a definition of "network."  Radio
networks have been subject to constant monitoring
for many decades.  Fast forwarding to SDNs and Cloud
Computing services, renders most of these this efforts
irrelevant.

Then after proffering a definition, the religious statement
appears: "we presume a priori that communications systems
should aim to provide appropriate privacy guarantees to
their users, and that such pervasive surveillance is therefore
a bad thing."  "Presume a priori?"  There are innumerable
contexts where privacy - which is itself a socio-political-
legal abstraction - is not relevant or applicable.

Similarly, the "perfect passive adversary" definition is a
self-contradiction.  If the observer is taking no action,
there is no threat by definition.

> We explicitly assume the PPA does not have the ability to compromise
> trusted systems at either the initiator or a recipient of a
> communication.
Give me a break.  Here again, an assertion is made that
is simply not credible.  Essentially all systems are
capable of compromise - either technically, lawfully,
or through insider threats (which is generally regarded
as the greatest threat).

If you want to analyze any of this within the context of
substantive ongoing work, you should consider applying
the STIX threat analysis/exchange model.

This kind of work tends to turn the IETF into a script
writing exercise for the third season of VEEP.

--tony

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Oct 2013 17:29:04 +0100

Hi Tony,

(Subject lines are cheap and helpful, let's try use
'em a bit better please.)

> concatenate the two notions together.

I don't see the contradiction. I'm sure wordsmithing will
be needed of course, and we'll want a better definition
of pervasive monitoring for sure. (See earlier comments
on the draft in the list archive.)

> You 

s/You/the draft/ I guess.

> also don't deal with timeframes.  Most Big Data

Timeframes are an interesting aspect to consider, I agree.

> Computing services, renders most of these this efforts

Huh? I don't get what you mean.

> a bad thing."  "Presume a priori?"  

Yep. For this draft, such an a-priori assumption is ok
I think - the point is so that when its done (and its a
-00) it'll be useful for protocol designers who need to
consider this threat model.

So its not at all "religious" here (and incidentally,
I figure such terms are purely pejorative, and not
generally helpful).

> There are innumerable

Can you enumerate some real cases where someone might
be designing an Internet protocol and where privacy
is irrelevant or not applicable?

That kind of scoping could be useful, if such cases
exist.

> Give me a break.  

Ok, take a break:-)

> Here again, an assertion is made that

As it happens I also commented on the definitions, and I
agree they do need work - that's what'll happen as the
draft progresses.

> the STIX threat analysis/exchange model.

Do you mean this? [1]

S.

[1] http://stix.mitre.org/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Oct 2013 17:49:29 +0100

...
>> So while I can see problems with MTU, I think genuine MTI (and perhaps
>> some MTU) is needed for privacy enhancements at a level that matches
>> the MTIs and MTUs for security.  I technical neutrality requires it.

That's not an unreasonable answer. However, we do have to
face the fact that a lot of times MTI stuff is just not
used when you and I would probably argue that it really
ought be used. It also not unreasonable to say that doing
more-than-MTI won't fix that, but that's what I'd like
to explore here.

> MTU mechanisms that you support?

Good question. Without saying I "support" it, rtcweb does
mandate more than MTI for e.g. DTLS-SRTP - the current
draft [1] says it MUST be offered as the default. I think
I'd maybe "support" it more if I understood better what
kind of key management  will be behind that, which I don't
yet, but its a data point for what a lot of folks think
will be an important protocol that does take a more-than-MTI
approach.

Maybe someone who knows more about that can explain the
reasoning behind that decision and whether they think it
could or should be generalised?

Other examples could be good too, esp if they're actually
used and not just RFC 6919 text;-)

S.

[1]
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.5

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 14 Oct 2013 19:04:01 +0200

>concatenate the two notions together.

You can resolve this by taking it as meaning everyone is a target, or
simply accept that this is a common and easily understood construction
just like we might talk of a "dry lake" even though we normally under-
stand a lake to be a water body.

>there is no threat by definition.

It seems to me the "passive" here is jargon and meant with respect to
"the bits on the wire". An "active" attacker would manipulate bits on
the wire, while a "passive" one does not; that does not stop them from
taking other actions than manipulating the bits on the wire. Also, it
should be clear that observation is an action and a threat by itself.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 13:39:16 -0400

Stephen,
...
> more-than-MTI won't fix that, but that's what I'd like
This may be where we have a significant disagreement. I am comfortable
developing security/privacy mechanisms that users and providers may
choose to employ, because compliant implementations will make it 
available in an
interoperable fashion. Insisting that a set of such mechanisms be employed,
seems beyond our remit.
> Good question. Without saying I "support" it, rtcweb does mandate more 
> than MTI for e.g. DTLS-SRTP - the current draft [1] says it MUST be 
> offered as the default. I think I'd maybe "support" it more if I 
> understood better what kind of key management will be behind that, 
> which I don't yet, but its a data point for what a lot of folks think 
> will be an important protocol that does take a more-than-MTI approach. 
> Maybe someone who knows more about that can explain the reasoning 
> behind that decision and whether they think it could or should be 
> generalised? Other examples could be good too, esp if they're actually 
> used and not just RFC 6919 text;-) S. [1] 

6919's "MUST (but we know you won't) was motivated by security MUSTs in 
a wide range of
docs. the RTCWEB doc isn't an RFC yet, so we'll have to see what 
happens.  Also, this is
an arch doc. As the author of 4301, the IPsec arch doc, I can attest 
that very, very few
implementation are compliant with all of it's MUSTs. Implementors tend 
to focus more on
bits on the wire than on other protocol "features"

Steve

---

From: joel jaeggli <[email-masked]>
Date: Mon, 14 Oct 2013 10:42:01 -0700

> I suspect, but cannot prove, that most users would express similar feelings.

the browser/CA transition from 1024 to 2048 bit certs is ongoing albiet done soon. That's a cost that everyone is paying for whether they know it or not… We therefore have an internet scale existence proof.

> 
> 
> I remember the same argument from the last decade when the Internet transitioned from TELNET to SSH. Some people said SSH would cause to much internet traffic and the servers could not handle the extra crypto.
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 13:50:36 -0400

Ralf,
> If this is the case why dont we hand a copy of our house key to the 
> police? This way the police can come around every evening and check 
> what we are up to.
An exaggerated, poor analogy, but I suspect you know that.
> Why not cameras on toilets as well?
maintenance issues?
> Because mass surveillance (for good and bad) scares the Internet user. 
> It makes it less attractive to use the Internet. It restricts the 
> Internet. It violates the Universal Declaration of Human Rights (to 
> which your country is a signatory as well).
As Stephen noted, Internet standards are used throughout the world, so 
whether a given country is
a signatory to the UDHR seems irrelevant.

If most users feel that security and privacy are high priorities, why do 
so many users download
free apps that monitor aspects of mobile phone use and direct ads 
accordingly? My position, in
part, is that people behave in a fashion that suggests that personal 
privacy is not a very
high priority when it comes to use of the Internet.
> It is not the targeted surveillance but the unregulated mass 
> surveillance that is the problem.
>
On what objective basis can one say that, i.e., who gets to decide what 
is "sufficient?"

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 13:51:19 -0400

Ralf,

I don't recall such comments. perhaps we travel in different circles.

Which IETF meetings have you attended over the past 20 years?

Steve
> transitioned from TELNET to SSH. Some people said SSH would cause to 
> much internet traffic and the servers could not handle the extra crypto.
>

---

From: Brian Trammell <[email-masked]>
Date: Mon, 14 Oct 2013 19:57:13 +0200

hi Stephen, Tony,

a few further points inline...

> on the draft in the list archive.)

Although I don't represent the clarity or quality of the draft as anything other than -00, I also don't understand what's not clear here.

For those who don't have 6973 open in front of them:

"Surveillance is the observation or monitoring of an individual's communications or activities... [and] can be conducted by observers or eavesdroppers at any point along the communications path."

The argument is that this definition is deficient, in that it presumes an individual target. The whole conceptual framework of surveillance as an activity presumes a target. Legal surveillance requires one in order to get the necessary documents signed by the necessary oversight authority. Illegal surveillance generally has one in mind because it's cheaper that way.

(One could make a case that there are indiscriminate attacks by criminal networks, e.g. skimming keystrokes from compromised machines to search for credit-card numbers... while these are untargeted with respect to individual, they're also not really surveillance per 6973, in that it's specific types of data that's the goal of the eavesdropping, not the communication or the activity in general.)

"Pervasive surveillance" (to mangle the 6973 defintion) is "the observation or monitoring of all individuals' communications or activities." Removing the concept of targeting (even if targeting is done after the fact) changes the character of the activity, both in terms of its impact on the monitored individual(s) (and -- at the risk of getting too far from the engineering -- its impact on the civil society of which the monitored individuals are presumed to be members) and in terms of how the impact it has on protocol design. Specifically, in targetless surveillance, attempts not to become a target are meaningless. (Which goes back to someone's... I think it was Yoav's... stated desire to increase the cost of pervasive surveillance to the point that he dropped out of the target set, which captures nicely the level of sensitivity we have to infinite versus finite target sets.)

> Timeframes are an interesting aspect to consider, I agree.

+1. I think we should assume they are for all intents and purposes infinite.

> Huh? I don't get what you mean.

I'm also confused, but I'm going to take a guess.

If by "cloud computing" you mean that protocols are being replaced by services, then yes, this is a problem. Nothing we can do on the network can protect against "PRISM"-class surveillance activities, by which I mean at least one endpoint of the communication (in this case, your email provider) cooperates with the observer. One could advocate the use of messaging protocols with end-to-end encryption of everything, as discussed in another thread on this list I've had to only halfway follow, as a workaround here. But then you'd have to come up with another business model to pay for email than the one we've arrived at to date.

> consider this threat model.

The "limiting assumptions" of the threat model need, I think, to be more explicitly stated as such.

>> there is no threat by definition.

As Björn pointed out, "passive" here is measurement jargon, opposed to "active": a passive adversary acts only as an observer, and cannot modify any traffic along the path. All they can to is observe. The question is: given that, what can they know? An observer that wanted to do much more and was positioned to do so could, of course -- there's a tradeoff here in terms of risk of detection of the observer.

(As an aside, I'll note that "perfect passive adversary" collides with a related-enough-to-be-dangerous term in the anonymity literature, such that it will be renamed in a future revision.)

> agree they do need work - that's what'll happen as the

And this is another limiting assumption. We are explicitly not treating these compromises _in this threat model_. Why? First, because if the observer owns your terminal or the terminal at the other endpoint, there is nothing you can do as a protocol designer. The game is over. What to do in that case is best handled at layer 9. We also make the explicit assumption that crypto works as advertised. That's also a risky assumption. Why do we make it? Because it's best treated somewhere else (and by someone else -- I learned years ago, when I was young and didn't know any better, with a home-spun Blowfish implementation, that I'm no cryptographer).

Best regards,

Brian

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Mon, 14 Oct 2013 19:30:38 +0100

> high priority when it comes to use of the Internet.
That's like saying "People should not have airbags because they should not
drive ruthless or fast in the first place. They surely do not care about
their safety so why should we invent the airbag?".

regards,

Ralf

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 14 Oct 2013 14:55:45 -0400

Hi Brian et al.,

This has been kind of fun to watch - based
on someone's note about it.  But I'm not
into this kind of far out academic religious
stuff and have real work to do.

But have fun.

--tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Oct 2013 08:13:13 +1300

On 15/10/2013 06:57, Brian Trammell wrote:
...
> If by "cloud computing" you mean that protocols are being replaced by services, then yes, this is a problem. Nothing we can do on the network can protect against "PRISM"-class surveillance activities, by which I mean at least one endpoint of the communication (in this case, your email provider) cooperates with the observer. 

A realisation I had while watching "Terms and conditions may apply" on Sunday
is that it's even worse. Given the weak privacy protection on the social
networks, a very large amount of traffic analysis and personal behaviour
analysis is possible without needing the cooperation of even one endpoint.
You just scrape stuff off the social network, squirt it through HADOOP,
and out comes a list of targets worthy of detailed investigation.
That is definitely part of today's threat model.

I'd say we actually have a hierarchy of threats to consider, starting with
'big data' analysis of publicly available data and ending with traditional
personally targetted wiretapping.

   Brian C

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Oct 2013 15:26:40 -0400

> high priority when it comes to use of the Internet.

While I have some sympathy for the above, I think it runs the risk of
a considerable oversimplification of the behaviour model of users.
Most importantly, I think it contains in it the sort of picture of end
users that is frequently part of _homo economicus_: a rational,
good-maximising agent.  Just as in economics, however, I suspect that
peoples' security decision-making actually relies on a number of
principles that we can scarcely believe are rational.  For instance,
it could just as easily be that people using privacy-invading apps
have convinced themselves of the utility of data protection policies,
or think that they're too individually insignificant for anyone to
care about.  There could also be (suppressed) cognitivie dissonance
involved.  Finally, there's the issue of how usable much of the
security support in systems is when actual users encounter it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Oct 2013 15:33:45 -0400

>
>     If most users feel that security and privacy are high priorities,
>     why do so many users download
>     part, is that people behave in a fashion that suggests that
>     personal privacy is not a very
> That's like saying "People should not have airbags because they should 
> not drive ruthless or fast in the first place. They surely do not care 
> about their safety so why should we invent the airbag?".
>
> regards,
>
> Ralf
Your proposed analogy is really, really bad, yet again. But it does provide
a good basis for a better analogy.

Seat belts are an example of an MTI, mandated by government-level 
regulations.
There are state laws in the U.S. that make them MTU, in 33 states. Note that
the MTU provision is a weak one; an audible warning sounds for a few 
seconds,
and then is silent. If one were very serious about seat belt use, there 
could
be an ignition interlock. But, since seat belt use is not mandatory in all
U.S. states, such an interlock would be problematic for vehicle 
manufacturers.

Air bags were initially an alternative, passive restraint option, viewed as
equivalent to 3-point seat belts, when passive restraints were first 
mandated
in  1984 (for vehicles produced in 1989), and the regulation applied 
only to drivers,
not passengers. In 1998 the rules were changed to mandate airbags in 
addition to
(3-point) seat belts, for front seat passengers, as well as drivers.

Over time vehicle manufacturers have voluntarily added more air bags in 
cars,
as a selling point, i.e., they perceive that some buyers will pay more for
knee bags, etc.

So, some take aways from this (corrected) analogy are

     - MTI can be appropriate for safety (security/privacy) features

     - MTU is a problem for such featyures when products are used across 
a wide range of
       jurisdictions

     - a safety (security/privacy) feature will be offered by vendors 
(service providers)
       when they that it is valued by their customers

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 14 Oct 2013 11:42:23 -0400

> public sector data collectio
 n has obviously blurred as more and more data is exchanged between the two,
but that does not make the two of them equivalent.
I appreciate your analysis, but I don't necessarily agree with your
conclusions. The state has a responsibility to provide for the security of
its citizens. To the extent that surveillance supports this goal, it is
potentially justified, irrespective of whether every citizen agrees with the
methods. Corporate collection of personal data tends to be driven by greed,
not quite so noble a goal :-).

I agree that the state has a more powerful capability to collect info about
Internet users, and yes, there are no T's & C's to read and agree to (or,
more likely ignore and agree to). But that does not mean that we, as
developers of Internet standards, are in a position to know whether all
users feel that state vs. corporate surveillance is a greater personal
concern, and thus warrants mandatory to use (vs. implement) security
features.
> For the list: much of this thread's discussion seems to presume that the
business considerations behind individual companies' decisions about whether
to deploy secure protocols or not are unchanged from what they were four
months ago prior to the beginning of the revelations. Yet elsewhere there
seems to be a whole lot of hand-wringing going on about how much business is
being lost or how nervous various customers are in the wake of the
revelations. Can we really assume that no IT managers in charge of
enterprise SIP deployments or middlebox-based backwards-compatability
solutions are even considering re-evaluating how they balance competing
requirements?

[RS> ]  Short answer. No.  Especially if the cost far outweighs the
benefits.  

I'll defer to folks with more direct experience with these businesses, but I
have seen no such change in perception. The only change I have seen is that
enterprises makign use of cloud storage and backup are more concerned about
the confidentiality of the data stored there, and are considering offshore
alternatives.

Steve

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 14 Oct 2013 22:33:25 +0000

Would you agree though Steve that wearing seat belts is our best current practice for safety, and that we (if we imagine ourselves car designers) should explain to people how unsafe the roads are and that they really should wear seat belts? Not everyone who builds cars might feel like they need to take responsibility for explaining this, of course, but some will.

I don't want us to throw up our hands and say there's nothing to be done to improve the situation because users don't understand security and some deployments would resist it. Here in the IETF, our responsibilities as participants differ from those of users and even operators. We write standards. I think we need to write standards that are clear about what people should do to be secure on the Internet as we understand it. Our understanding of the Internet has changed because of these revelations, and what we need to do has to change as well. I agree that we can't levy unrealistic mandates and hope for anything but our own irrelevance. But let's not swing too far in the opposite direction here either.

Jon Peterson
Neustar, Inc.

From: Stephen Kent <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 14, 2013 12:33 PM
To: Ralf Skyper Kaiser <[email-masked]<mailto:[email-masked]>>
Cc: perpass <[email-masked]<mailto:[email-masked]>>
Subject: Re: [perpass] mandatory-to-implement vs. more?

If most users feel that security and privacy are high priorities, why do so many users download
free apps that monitor aspects of mobile phone use and direct ads accordingly? My position, in
part, is that people behave in a fashion that suggests that personal privacy is not a very
high priority when it comes to use of the Internet.

That's like saying "People should not have airbags because they should not drive ruthless or fast in the first place. They surely do not care about their safety so why should we invent the airbag?".

regards,

Ralf

Seat belts are an example of an MTI, mandated by government-level regulations.
There are state laws in the U.S. that make them MTU, in 33 states. Note that
the MTU provision is a weak one; an audible warning sounds for a few seconds,
and then is silent. If one were very serious about seat belt use, there could
be an ignition interlock. But, since seat belt use is not mandatory in all
U.S. states, such an interlock would be problematic for vehicle manufacturers.

Air bags were initially an alternative, passive restraint option, viewed as
equivalent to 3-point seat belts, when passive restraints were first mandated
in  1984 (for vehicles produced in 1989), and the regulation applied only to drivers,
not passengers. In 1998 the rules were changed to mandate airbags in addition to
(3-point) seat belts, for front seat passengers, as well as drivers.

Over time vehicle manufacturers have voluntarily added more air bags in cars,
as a selling point, i.e., they perceive that some buyers will pay more for
knee bags, etc.

    - MTU is a problem for such featyures when products are used across a wide range of
      jurisdictions

    - a safety (security/privacy) feature will be offered by vendors (service providers)
      when they that it is valued by their customers

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Oct 2013 00:41:36 +0100

Hi Steve,

On 10/14/2013 06:39 PM, Stephen Kent wrote:
> This may be where we have a significant disagreement. 

Note that I've no espoused any particular more-than-MTI
position so its not yet clear how you and I disagree
(on this one:-)

> I am comfortable

I get that argument. But what's the difference between that
and saying "don't use MD5" really? We're comfortable with
the latter since MD5 is just broken for collisions. I don't
see why we shouldn't be equally comfortable in saying "don't
send cleartext" - *if* that's an IETF consensus position - as
we have seen sending cleartext is also just broken when one
consideres pervasive monitoring.

In fact I don't really believe there's a crystal clear line
between protocol and policy in many cases, I think its blurrier
than is claimed by those who argue against more-than-MTI as
being beyond our remit, as you do.

That doesn't by itself invalidate your basic position that MTI
is good enough of course, but personally I do think it means
that a more-than-MTI position could exist that is equally
as defensible as the status quo.

> bits on the wire than on other protocol "features"

Its not like 4301 and that draft is I think nearing LC and code
that does this (again I think) has been deployed, possibly widely,
though I think I do recall some part where one of the popular
browsers doesn't do the DTLS thing for data channels or some
such, so I'm not claiming its a perfect example, but it is a
real one.  Again I'd be interested in hearing from folks who
were involved in that discussion or who know more about the
reality of rtcweb code and deployments.

But this is a real example where we are specifying more-than-MTI
for one important protocol already, I think that's unquestionable
frankly.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Oct 2013 11:26:06 +0100

Following up on my own point - not stylish but I think
in this case justified:-)

On 10/15/2013 12:41 AM, Stephen Farrell wrote:
> I don't

I guess this Washington Post story [1] that I saw this
morning would appear to provide a relevant example.

In that case, I would argue that the fact that cleartext
IMAP provides interop and is successful does imply that
some services somewhere will use that for large populations
that will inevitably (as we now know) be subject to
pervasive monitoring.

When the numbers involved ("500,000 buddylists and
inboxes" collected on a "representative day" for just
one agency) are at that scale, then it seems to me that
one can fairly describe that as a failure in protocol
design and not solely as a bad deployment choice.

With the 20-20 hindsight afforded, if IMAP were a new
protocol, would we be correct to only have TLS as MTI as
we currently do [2] or would the Internet be better
if we *only* had port 993 and had TLS as MTU perhaps
with anon DH or something (*) like that?

The latter approach is certainly now far more likely to
be tractable than it was in 2003 (when RFC3501 was done).
Maybe its time we do that.

Cheers,
S.

(*) Yes, there's a bit of arm-waving there since one
can validly argue that the TLS ciphersuite that's MTI
for 3501 is still just a bit too hard to deploy as
one is supposed to get a server cert that the UA can
verify, which implies some management overhead. So
something slightly more easily deployed (and hence
not quite 3501) might really be needed. But *how* to
do MTU stuff could be a protocol-specific debate to
have after we concluded we had consensus for
more-than-MTI in some form. (Which we don't, today.)
But of course, a new IMAP security BCP doesn't have
to wait either (hint, hint:-)

[1]
http://www.washingtonpost.com/world/national-security/nsa-collects-millions-of-e-mail-address-books-globally/2013/10/14/8e58b5be-34f9-11e3-80c6-7e6dd8d22d8f_story.html
[2] https://tools.ietf.org/html/rfc3501#section-11

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Oct 2013 11:18:56 +0000

> with anon DH or something (*) like that?

But with anon-DH you're not making those large populations less subject to pervasive monitoring. You've only made it a bit more difficult, and not in a way that is significant to the adversaries we're talking about. 

You would get them better security if they were doing TLS with mutual authentication, but that requires a lot of infrastructure, and you would hesitate to mandate that even if IMAP was a new protocol. You added "perhaps with anon DH" because you know what response you would get if you had said instead "with mutual authentication and PFS".

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Oct 2013 12:31:50 +0100

Hiya,

On 10/15/2013 12:18 PM, Yoav Nir wrote:
> But with anon-DH you're not making those large populations less
> subject to pervasive monitoring. You've only made it a bit more
> difficult, and not in a way that is significant to the adversaries
> we're talking about.
> 
> You would get them better security if they were doing TLS with mutual
> authentication, but that requires a lot of infrastructure, and you
> would hesitate to mandate that even if IMAP was a new protocol. You
> added "perhaps with anon DH" because you know what response you would
> get if you had said instead "with mutual authentication and PFS".

In this case, it appears (but we don't know) that the
monitoring was done at a lower layer and a mitm would
arguably be more expensive and more detectable, so even
anon DH might help enough to get Yoav's inbox off the
list of those 500,000 getting snarfed each day.

But, that's really discussing the IMAP-specific "how
to mitigate" and the more interesting question I think
is whether we should regard this report as an existence
proof of a protocol design failure that's had the
spotlight shined on it a decade after 3501 was published,
or as a mere case of deployments that didn't do the
right thing.

S.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Oct 2013 15:40:36 +0200

>they can be turned on and the rest is policy.

I need to monitor everything that comes in and out of my computer
systems and networks so I can detect exfiltrations and intrusions,
like when the latest operating system update comes with a helpful
default-on automatic cloud backup solution for my encryption keys,
or detailed information about nearby radio signals and microwaves
collected over prolonged periods of time by my smartphone. Lacking
a mandate to allow the user to effectively disable any "security"
mechanism would also help those who want to "pervasively monitor
everything", but "mandatory-to-use" digital repression mechanisms
are being deployed faster than I can track them. That would seem
to belong to this debate aswell.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 15 Oct 2013 10:44:58 -0400

Pardon the intervention, but when you scrape
some traitor's stolen material from Washington's
tabloid press as your use case, it is embarking far
into WTF territory.

The activity described in the material appears
not only to be perfectly legal, but consonant
with the fundamental purpose of the agencies
and communities involved.  It is consonant
with activities with a continuum over many
decades.  It is also essential to discovering
active planning designed to bring about
substantial harm to people and infrastructure.

One gets the feeling that if an Al-Shabaab IT
guy sent a Dear PERPASS email, asking if
the IETF could be its service bureau for secure
communications to plan its next mass killing
at a shopping centre, the answer would be
"sure enough" as we're concerned about your
privacy rights.

On 11 Sep 2001, as fate had it, I was on one
of the suspect planes in the air.  So perhaps
you can understand the interest in preventing
a similar event - which was coordinated via
Internet messages - as well as a certain
disdain for what seems to be ensuing here.

--tony

On 10/15/2013 6:26 AM, Stephen Farrell wrote:
>> >send cleartext" -*if*  that's an IETF consensus position - as

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Oct 2013 11:42:30 -0400

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Oct 2013 12:21:26 -0400

> tabloid press as your use case, it is embarking far

One problem is that the traitor in question was employed by the NSA and was
able to operate undetected for several years.

We have seen the greatest breach of internal security in NSA history and
nobody has been held accountable at a senior level.

Organizations that do not hold themselves accountable get held accountable
through external means. In this case pervasive unaccountable surveillance
is going to be met with pervasive unaccountable encryption.

Of all the evils in the world, where does snuffing out democracies in
Chile, Iran, Brazil, Greece and the rest stand next to terrorism? Pinochet
alone murdered more people than all the terrorists of the 20th century did.
Where does starting an illegal war that causes a half million deaths stand?

This is an international organization.

Suggesting that we leave such matters to those in authority without
specifying which authorities makes a large set of assumptions that are
probably more apparent to those of us who are not US citizens.

You might think it improper for someone like me to question the decisions
of your government. I think it rather presumptuous for US citizens to
assume that control of the Internet should lie exclusively with their
government because none of the rest could ever be trusted.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Oct 2013 17:25:56 +0100

Tony, Phill, (and everyone else)

Please - this and Tony's last mail are inappropriate
for this list and probably any IETF list.

Please don't continue it further.

Thanks,
Stephen. (As list moderator)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 14:03:42 -0400

Jon,
> Would you agree though Steve that wearing seat belts is our best 
> current practice for safety, and that we (if we imagine ourselves car 
> designers) should explain to people how unsafe the roads are and that 
> they really should wear seat belts? Not everyone who builds cars might 
> feel like they need to take responsibility for explaining this, of 
> course, but some will.
Taking this analogy too far ...

Yes, I'd support a BCP that calls for wearing seat belts. I would object 
to a standard
for cars that prevents them from starting unless the driver and 
passenger seat belts
are fastened, and prevents them from being unbuckled until the car is 
shifted into "park."
> I don't want us to throw up our hands and say there's nothing to be 
> done to improve the situation because users don't understand security 
> and some deployments would resist it. Here in the IETF, our 
> responsibilities as participants differ from those of users and even 
> operators. We write standards. I think we need to write standards that 
> are clear about what people should do to be secure on the Internet as 
> we understand it.
There certainly are things that can be done to improve security, in 
terms of our standards. We
should explain to people what that MAY do (not MUST or SHOULD) to be 
more secure. We're neither
Internet police nor Internet nannies.
> Our understanding of the Internet has changed because of these 
> revelations, and what we need to do has to change as well. I agree 
> that we can't levy unrealistic mandates and hope for anything but our 
> own irrelevance. But let's not swing too far in the opposite direction 
> here either.
Competent security folks were not surprised by the technical 
capabilities that have been revealed.
It's obvious that one can gain access to tons of metadata with the 
assistance of service providers,
and that a first world country can (and would) analyze that data looking 
for bad guys.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 16:49:16 -0400

Joel,
> the browser/CA transition from 1024 to 2048 bit certs is ongoing albiet done soon. That's a cost that everyone is paying for whether they know it or not… We therefore have an internet scale existen…
Which RFC mandated this? My guess is NONE.

This represents a decision by a set of CAs and browser vendors, external 
to the
IETF, to improve security. That's fine, but it is also not 
representative of many
of the suggested mechanisms that have been proposed on this list, by 
some folks.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 17:00:25 -0400

Brian,

...
> "Surveillance is the observation or monitoring of an individual's communications or activities... [and] can be conducted by observers or eavesdroppers at any point along the communications path."
a reasonable definition, when we are focusing on cyberspace.
> The argument is that this definition is deficient, in that it presumes an individual target. The whole conceptual framework of surveillance as an activity presumes a target. Legal surveillance requ…
I would not interpret the definition that narrowly, just because it 
mentions an individual.
Surveillance directed against a class of individuals seems to fit here 
as well.
> (One could make a case that there are indiscriminate attacks by criminal networks, e.g. skimming keystrokes from compromised machines to search for credit-card numbers... while these are untargeted…
I'd disagree here too. Grabbing keystrokes is one way to get a password 
or a credit card number
at the source, an alternative to wiretapping. The goal would be the same 
for an adversary, independent
of the means by which it is accomplished.
> "Pervasive surveillance" (to mangle the 6973 defintion) is "the observation or monitoring of all individuals' communications or activities."
I suspect that the Internet is too big even for NSA and its friends to 
observe _all_  individuals, so
this definition seems too narrow, in a different way.
> Removing the concept of targeting (even if targeting is done after the fact) changes the character of the activity, both in terms of its impact on the monitored individual(s) (and -- at the risk of getting too far from the engineering -- its impact on the civil society of which the monitored individuals are presumed to be members) and in terms of how the impact it has on protocol design.
I suspect that the sort of very widespread surveillance that we have 
been discussing is still
targeted, in a sense. It may target users of specific providers or 
specific web sites, either
because the folks performing surveillance believe those are good places 
to gather the data
of interest, or because those are places within their ability to 
surveil. (Remember the joke
abut the drunk looking for his car keys under the street lamp, not 
because he lost them
there, but because the light was better?)
> Specifically, in targetless surveillance, attempts not to become a target are meaningless. (Which goes back to someone's... I think it was Yoav's... stated desire to increase the cost of pervasive surveillance to the point that he dropped out of the target set, which captures nicely the level of sensitivity we have to infinite versus finite target sets.)
I understand Yoav's model, and it has a rational basis. However, I have 
concerns about increasing
the "cost" for all users of some service, to make it easier for Yoav to 
avoid being targeted. This
seems like an externalization of cost, not my favorite economic model.

Steve

---

From: joel jaeggli <[email-masked]>
Date: Tue, 15 Oct 2013 14:03:04 -0700

> Which RFC mandated this? My guess is NONE.

the recommendation comes from nist 800-131A and 800-57  I'd link to them if the nist website were up but it isn't.

> This represents a decision by a set of CAs and browser vendors, external to the
> IETF, to improve security.

I'm not particularly enamoured of the idea the the IETF is the sole or even principle arbiter of industry consensus, so lets assume that it isn't. Whether you want to pay the cpu consumption tax or not, there's enough industry consensus on the subject that you don't have a choice.

> That's fine, but it is also not representative of many
> of the suggested mechanisms that have been proposed on this list, by some folks.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Oct 2013 22:16:49 +0100

Steve,

> and that a first world country can (and would) analyze that data looking

Competent people have been surprised by the scale here.
The level of collusion and coercion was not obvious to
many.

>From their pre-shutdown reaction, NIST appear both to
be surprised and to think something non-obvious has
occurred and I'm sure you'd consider NIST's crypto
people as being competent.

I think your comment above subtly understates the
situation in a way that's just not credible.

The subtlety is nicely done though:-)

S.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 17:21:21 -0400

Hello,
> position so its not yet clear how you and I disagree
I must have misunderstood your comments (on this one :-) )
> consideres pervasive monitoring.
Saying don't use a specific alg, because it's defective, is a mandate
within a context where users/providers have already decided to employ
a security mechanism. Saying"no cleartext" is a statement without that
context, and thus not analogous. Or, in a lighter analogy, in the first
case we know what kind of people we're talking about, and we're just
haggling over the algorithm ;-) .
> being beyond our remit, as you do.
There may some gray areas; when I asked Avri about this she demurred,
so we'll have to examine specific examples to make progress.
> as defensible as the status quo.
Again, we'll have to see what more-that-MIT positions are put
forth before we'll be able to resolve this speculation on both
of our parts.
> reality of rtcweb code and deployments.
In the RTCWEB case is the difference that  "a major browser vendor" has
decided its good, so it's a done deal? Frankly I've become concerned, 
recently,
that one major browser vendor has become very pushy about its ideas of 
what is
best for everyone. Because that vendor also is an OS vendor, it's
influence seems outsized, to me. But that's a different rant.
> for one important protocol already, I think that's unquestionable
OK, and frankly, I think this is a questionable idea.

I just skimmed the I-D in question. It has over 80 MUSTs. Given the 
rather poor
track record of browsers wrt security,I am amazed to see the following 
text, in Section 3:

    The basic assumption of this architecture is that network resources
    exist in a hierarchy of trust, rooted in the browser, which serves as
    the user's TRUSTED COMPUTING BASE (TCB).

I suspect that most IETF participants are not familiar with the term TCB 
(and
there is no cite in the I-D), so they do not realize how odd this 
statement seems
to those of who are familiar with the term.

I have a lot of respect for Eric, but ...

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Oct 2013 22:28:23 +0100

> forth before we'll be able to resolve this speculation on both

Fully agree. Brian Carpenter mentioned one in an earlier
mail (on-by-default with an option to turn off) but we've
not seen others proposed so far.

S.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 15 Oct 2013 23:44:55 +0200

hi, Stephens,

+1 (again) to MaD (mandatory as default); I've been following the thread and trying to thing of an MTU mechanism that is meaningful in an IETF context. Unfortunately for that, that we've done a reasonably good job of layering security -- making it simple to integrate in makes it simple to separate out as well.

I really think the best we can do is MaD with guidance for usage that enumerates specific, limited cases in which it makes sense to turn off.

Cheers,

(another) Brian

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 17:52:15 -0400

Joel,

Thanks for the quick reply.
...
> the recommendation comes from nist 800-131A and 800-57  I'd link to them if the nist website were up but it isn't.
OK, then, as I suspected, this is not the result of any RFC.

> I'm not particularly enamoured of the idea the the IETF is the sole or 
> even principle arbiter of industry consensus, so lets assume that it 
> isn't. Whether you want to pay the cpu consumption tax or not, there's 
> enough industry consensus on the subject that you don't have a choice.
I agree that the IETF is not an arbiter of industry consensus. The 
question being debated on this
list is whether it ought to become more of an arbiter of what users and 
service providers do,
by mandating use of security mechanisms, vs. just offering specs for 
interoperable mechanisms.

BTW, who got to form the industry consensus this time? How many folks, 
and in what venue?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 17:55:31 -0400

Stephen,
> The level of collusion and coercion was not obvious to
I was not addressing the level and scale of collusion.
I was noting that the vulnerability was always obvious,
and if one was concerned about the confidentiality of metadata, ...
> The subtlety is nicely done though:-)
The comment about NIST was not from me, although I
too admire subtlety in such contexts.

Steve

---

From: [email-masked]
Date: Tue, 15 Oct 2013 11:13:34 -0700 (PDT)

> that will inevitably (as we now know) be subject to

What is this "cleartext IMAP" of which you speak? A quick check of some of the
major US MSPs shows that Gmail, Hotmail, and Apple all require SSL/TLS for
IMAP. And AOL definitely offers SSL/TLS support, but I can't tell if they
require it or not.

Now, it seems to me like I'm missing one ... it's on the tip of my tongue ...
oh yeah, that would be Yahoo, the only vendor actually mentioned by name in the
Powerpoint slides the Washington Post story you cite is based on. But lo and
behold, they also require SSL for all IMAP access!

I haven't bothered to survey ISPs (although I will note that Verizon and
several others only offers POP, not IMAP, and yes, they do offer SSL with
that), but my sense is most of them support SSL/TLS and many even require it.

But don't for a moment think this is due to anyone caring deeply about privacy.
This is about support costs, specifically, the costs that accrue when someone's
account password is compromised, as it easily can be when using any of the
email protocols from, say, a wireless hotspot. SSL/TLS covering an AUTH
PLAIN/LOGIN exchange is the method of choice for addressing this problem, and
you end up getting SSL/TLS for the rest of the session for free when you do
that.

And before the IETF spends any time patting itself on the back here, I'll also
point out that almost all secure IMAP is imaps on port 993. IETF specifications
call for STARTTLS on the regular IMAP port (143). I also doubt that the
supported ciphersuites conforms all that well to IETF guidelines.

> design and not solely as a bad deployment choice.

And again I have to ask: What is the "protocol design failure" of which you
speak? I'm especially interested in the one the IETF has made that exposes
buddy lists and address books.

In case you weren't aware, IMAP does not handle address book information or
buddy lists. It's just not part of the protocol, unless you do something quite
outre like storing your address book as a special message in a special folder.

The IETF protocol that does do part of this is carddav, but it's a relative
newcomer on the scene, and while many MSPs, including Yahoo, support it, I
see no indication that it's involved here.

Rather, this all looks to me like it has a lot more to do with web access
to mail and IM, to the point where I'm skeptical that access to cleartext
IMAP is a significant factor. (There is a slide at the end about IMAP,
but it's oddly disconnected from the rest of the presentation, and seems
like something added as an afterthought.)

Something else not mentioned on the slides is ActiveSync. AFAIK ActiveSync is
the biggest player in the address book and calendar access protocol space right
now. And there may well be security issues in it. But since it's a Microsoft
creation, it's going to be tough for the IETF to do anything about any problems
it has.

> with anon DH or something (*) like that?

No, what 20-20 hindsight actually reveals is that when you fail to respond to
market needs, in particular the needs of mobile devices, in a timely and
appropriate way, alternatives to your protocols crop up that you have no
control over. And when those alternatives have security issues there's not all
that much you can do about it.

> to wait either (hint, hint:-)

... And that's a strawman. I've not heard and provider of any size make such an
argument in many, many, many years. The fact of the matter is that secure IMAP
*is* widely and successfully deployed, albeit in a way that the IETF did not
intend and in spite of the fact that the IETF did bugger-all to make it easy to
do. And since only yesterday I was listening to a presentation that among other
things covered the specifics of how a provider with 10s of millions of users
handles this particular problem, I can state with some authority that the costs
aren't that big a deal.

But if you really think it's worth spending the time to make IMAP security even
better, that's fine with me. But the work needs to be based on what's in play
in the real world, which seems markedly at odds with what you imagine is out
there. It also needs to be informed by what's actually possible given real
world constraints, e.g., what ciphersuites are actually offered by the SSL/TLS
libraries in common use. (I've heard it mooted that support for anon-DH in
particular is likely to be dropped from some of them.) And finally,
expectations as to what this will actually accomoplish in terms of thwaring
pervasive surveilance need to be lowered pretty dramatically.

But more generally - and I'm afraid I'm going to be a bit unkind here - there's
way too much yacketing about non-issues and completely impractical
non-solutions going on here, at least when it comes to securing the
bulk of present-day email.

So I'm once again going to ask, "What's the goal here?". If the goal is to make
the email of select group of cognescenti more secure that's one thing. It's
quite another to talk seriously about improving email security for everyone
else.

If we're going to do the latter, I'm afraid that needs to start with a better
understanding of what present-day email service actually looks like and where
market trends are pushing it. 

				Ned

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 15 Oct 2013 23:05:19 +0100

> are fastened, and prevents them from being unbuckled until the car is 
I observe that the car designers have gone quite a way down this path.
Today's default seems to be irritating and unsilenceable audio alarms
triggered when you drive off without belting up.

I agree that I don't think we would want to go that way with email even
if there was an equivalent to this analogy.

However the automatic (person strangling) seat belt seems to have had a
brief outing and disappeared again - or maybe I haven't driven the right
US cars recently. 

/Elwyn

---

From: joel jaeggli <[email-masked]>
Date: Tue, 15 Oct 2013 17:05:14 -0700

On Oct 15, 2013, at 2:52 PM, Stephen Kent <[email-masked]> wrote:

> I agree that the IETF is not an arbiter of industry consensus. The question being debated on this
> list is whether it ought to become more of an arbiter of what users and service providers do,
> by mandating use of security mechanisms, vs. just offering specs for interoperable mechanisms.
> 
> BTW, who got to form the industry consensus this time? How many folks, and in what venue?

I belive the vehicle for coordination that was the ca/b forum

www.cabforum.org

Tim Moses who is one of the wpkops co-chairs is also the chair of that iirc so I would defer to an expert there.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Oct 2013 01:30:53 +0100

Hiya,

Many snippets below...

On 10/15/2013 07:13 PM, [email-masked] wrote:
> What is this "cleartext IMAP" of which you speak? 

I guess that's a fair comment - we don't know that they're
able gather to inbox data via IMAP due to it being sent in
clear,  however that seems like a reasonable guess based
on the newspaper story which says that collection is done
by telcos that are "overseas" and assuming that TLS is not
busted for these services. (Even were TLS busted for those
services though, I don't think that changes so much of the
analysis *if* one can separately mitigate whatever's gone
wrong with those TLS deployments.)

But yes, that's guessing and we need to keep that in mind
and there could well be alternative explanations.

> A quick check of some of the

Is there publicly available information about the deployment of IMAP
in terms of how many servers/services allow or disallow cleartext,
STARTTLS or 993? (To expose my ignorance, yes, I did assume that many
services still allow IMAP over 143 without STARTTLS in addition to
993.)

> you end up getting SSL/TLS for the rest of the session for free when you do

Sure.

> call for STARTTLS on the regular IMAP port (143). 

Rught. An important point I think.

> I also doubt that the

Again, any information on what's available & what's used (if its
basically the same set of libraries as used for HTTP that's
probably known).

> speak? 

Basically, having three flavours of IMAP (clear, STARTTLS and 993)
where one that just mandated use of TLS could arguably be simpler
and more secure. And note - I'm not saying this should've been
done years ago, I'm asking if in a similar situation today we
ought go for the one-with-security or the 3-flavoured approach.

(Ignoring the rest of the message and just dealing with that
would be fine from my pov if that helps.)

> I'm especially interested in the one the IETF has made that exposes

Address books? When did I mention those? I don't believe I did and
if I did then that was in error. The buddylists things in the slides
are also presumably not IMAP related.

> creation, it's going to be tough for the IETF to do anything about any problems

Yeah, address books would be different, but again I don't
believe I even used that term in this discussion.

> that much you can do about it.

Hmmm. That may be true. But I don't think you answered
the question, except with the first word and then I'm
not sure if that's an answer or disagreeing with the
question.

Lemme try another way: if IMAP were a brand new protocol
today and given today's kit and network and what we've
learned, would we argue to define both an insecure and
a secure (but maybe not much used) variant or would we
be better off only defining one version that builds in
whatever we think is the right set of securiy features
and ensures that those are used (by not having the
option to not use 'em)?

> do. 

Yes - I think that supports my argument - the existence of a
"pretend" security variant at day zero is damaging so we should
ask whether we ought just make the security mandatory to use
and end up with one version.

> And since only yesterday I was listening to a presentation that among other

I don't get what you mean there.

> there. 

Disagree. But that (I hope) is because you misinterpreted what
I'm asking/saying.

> It also needs to be informed by what's actually possible given real
> libraries in common use. 

Yeah. There're similar issues for TLS in general.

> (I've heard it mooted that support for anon-DH in
> particular is likely to be dropped from some of them.) 

That's fair. I did acknowledge arm-waving though.

> And finally,

Why? And even if so, it may be worth doing as proection
against other bad actors.

> bulk of present-day email.

I think that's not unkind but is unfair. (Given that I think
you yacketed about address books above for example.)

> market trends are pushing it. 

Better understanding is always good and the main goal here (at least
mine) is to make pervasive monitoring more expensive to the extent
technically feasible. Personally, I think there are things about IMAP
that could be impoved but I'm very skeptical that we can "solve" the
problem for mail in general. (Some others on this list are more
optimistic.)

S.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Oct 2013 10:21:58 -0400

Joel,

Thanks for the followup, identifying the CABF as the source of the key 
length change.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Oct 2013 10:28:05 -0400

Stephen,

Just commenting on one of your comments ...
> busted for these services.
Based only on the story that you cited, and your observation about
telcos being the sources of the info, might it be the case that the
telcos were also the mail providers? I'm not sure how to interpret
the slides the the cite story included. That sort of explanation
would be consistent with Ned's observations about commercial provider
use of SSL to protect IMAP/POP access.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Oct 2013 15:46:24 +0100

> use of SSL to protect IMAP/POP access.

That could be but I guess we're not likely to be told;-)

I did take a peek to see if I could figure out if there're
lots of services running on 143 without STARTTLS but haven't
found anything that answers that question. I did find
this [1] (no idea how accurate though) which says their
survey found 4.7M listeners on 143, but there's no info
about how many have a usable STARTTLS config. With that
number of services, I guess collecting O(10^5) "inboxes"
per day in plaintext could be credible, but who knows.

But, nonetheless I think the question about 3-flavours
of IMAP and MTI is still worth thinking about.

S

[1] http://www.openemailsurvey.org/imap-143.html

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Oct 2013 11:23:35 -0400

Stephen,

I realized that I forgot to reply to your message about MTI vs. MTU for 
IMAP.

Even absent Ned's detailed note showing that most major e-mail providers 
already
mandate use of TLS for access, I would not see the Washington Post story as
evidence that we need to change IMAP (and POP?) to mandate _use_ of TLS. 
One reason
is that these e-mail access protocols are used in enterprise environment 
where passive
wiretapping often not considered a viable attack. Internal to the 
enterprise net
there is usually a perception of adequate physical security. For 
external access,
VPN use is usually mandated. If we mandated use of TLS with these 
protocols, and
access was already protected by IPsec, it would seem overkill, and 
create possible PMTU
problems.

This is another example of why it's hard to justify MTU for protocols, 
independent of
context. Ned's observations, and Joel's, suggest that when a service 
providers decide that
security against passive wiretapping is a concern, they make use of it 
(eventually),
irrespective of IETF mandates. It's disappointing that, as Ned noted, 
the providers
elected to adopt a different port for this protected access, contrary to 
IETF specs.
Maybe this shows that we're not always in the best position to decide 
the MTI details :-( .

Steve

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 16 Oct 2013 09:32:03 -0700

On Oct 16, 2013, at 8:23 AM, Stephen Kent <[email-masked]> wrote:
> One reason
> is that these e-mail access protocols are used in enterprise environment where passive 
> wiretapping often not considered a viable attack. 

As someone who remembers the switch to Kerberos and then SSH driven by password sniffers in the LAN, including one which got my own password back in the day, I find this assumption grossly unrealistic.

You have to REALLY lock-down the LAN, including properly configure high end switches with ARP filtering and/or other layer 3 management, for this assumption to be even remotely plausible.

Finally, we must consider passive wiretapping an active attack.  The only thing which prevents a passive wiretap from modifying (rather than just monitoring) traffic is almost invariably the will of the attacker, not any technical limitation, since even on-path wiretappers can packet inject, allowing the attacker to trivially promote themselves into a MitM situation in almost all circumstances.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Albert Lunde <[email-masked]>
Date: Wed, 16 Oct 2013 12:32:52 -0500

> evidence that we need to change IMAP (and POP?) to mandate _use_ of TLS.

Another concern might be that the Oauth 2.0 family of protocols, as used 
on various social medial, could be used to dump a "profile" for a user 
(which might include contacts).

There's not a lot of uniform cross-provider interop yet (in say, openid 
connect), but the per-provider extensions seem able to leak excessive 
user information in some use cases.

(Based on what I've read, I haven't looked at the traffic myself).

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: SM <[email-masked]>
Date: Wed, 16 Oct 2013 08:53:27 -0700

>competing in the marketplace.

I could do a study to find out which provider is popular in the 
IETF.  The result would probably be gmail.com.  There aren't that 
many providers competing in the marketplace.  It is difficult to 
compete when most users want a free service.  For what it is worth, 
there hasn't been any noticeable shift in providers used by IETF participants.

>based on their assessment of the risk.

If the IETF is a technical standards body it should not discuss about 
privacy in its specifications.  That would not go down well in 
practice as other bodies will point out that the IETF is designing 
standards without any thought to how it affects the users.

Security considerations are mandatory for IETF specifications.  I 
gather that there would be some guidance in that section so that 
people making implementation choices can assess the risks.

The topic in the subject line is about mandatory-to-implement.  If 
the feature is not available in an implementation the user has less 
choices.  The default setting also matters.  If a feature is off by 
default the average user won't turn it on.  Note that some 
implementations usually make that choice based on feedback from the 
users.  As an example, if the key length chosen by the user is 
considered as insecure, the implementation might generate a warning 
or exit with an error message.

Regards,
-sm

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Oct 2013 15:30:55 -0400

> As someone who remembers the switch to Kerberos and then SSH driven by password sniffers in the LAN, including one which got my own password back in the day, I find this assumption grossly unrealis…
That used to be a valid concern. I'm not sure why, but it seems to be 
less of a concern
today. Maybe use of VLANs, better switch management, ...
> You have to REALLY lock-down the LAN, including properly configure high end switches with ARP filtering and/or other layer 3 management, for this assumption to be even remotely plausible.
OK.
> Finally, we must consider passive wiretapping an active attack.  The only thing which prevents a passive wiretap from modifying (rather than just monitoring) traffic is almost invariably the will o…
I don't agree that we should ignore the differences between passive and 
active wiretapping.
I do agree that passive wiretapping can be augment with active attacks 
of various sorts.
It's not just the "will" of the attacker that matters; it's also the 
capabilities of the
attacker and their sensitivity to being detected.

Steve

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 16 Oct 2013 12:47:44 -0700

On Oct 16, 2013, at 12:30 PM, Stephen Kent <[email-masked]> wrote:
> I don't agree that we should ignore the differences between passive and active wiretapping.
> I do agree that passive wiretapping can be augment with active attacks of various sorts.
> It's not just the "will" of the attacker that matters; it's also the capabilities of the

Capability wise, there is nothing except cryptographic data integrity that prevents an eavesdropper from injecting their own traffic.  On HTTP, this enables redirecting the browser to an arbitrary site (for exploitation), extracting any not-SSL-only cookies, injecting arbitrary code at the end of a web page, etc.  Absent DNSSEC validation on the part of the victim, DNS injection allows the attacker to MITM any connection.  

Similarly, at layer 2, absent significant protection in the switch, properly configured, both DHCP and ARP injection allows similar total hijacking.  There are no capability limitations of note for a "passive" eavesdropper who wants to become active.

Thus it really is "will" as convenient shorthand: is the attacker willing to use this and chance getting caught if a subtle detector is actually looking for the signs of attack?

We need universal protection against active adversaries, because the precedents have been set and the distinction between passive and active really is the willingness of the adversary to include active techniques.  We need end-to-end data integrity on all communication and if you have end-to-end integrity, anything point-to-point rather than broadcast should also include confidentiality since you can just about get it for free by this point.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Oct 2013 21:23:48 +0100

Hiya,

On 10/16/2013 08:47 PM, Nicholas Weaver wrote:
> 
> We need universal protection against active adversaries, because
> the precedents have been set and the distinction between passive
> and active really is the willingness of the adversary to include
> active techniques.  We need end-to-end data integrity on all
> communication and if you have end-to-end integrity, anything
> point-to-point rather than broadcast should also include
> confidentiality since you can just about get it for free by this
> point.

While I sympathise with more protection and with moves towards
more-than-MTI, and I fully agree with you about LAN traffic, I
think also requiring e2e mutual auth (which I think is implied
in the above) would be counterproductive.

The problem is that that introduces a management problem into
every scenario and that management overhead is I think is (today)
the main reason why the most of the MTI security features we
define don't get traction until the exploits experienced by
users/networks become intolerable.

I think the path forward is more like making opportunistic
security mechanisms (in particular confidentiality) more-than-MTI
in a way that builds in some security (against passive attacks)
as an inherent feature of new protocols, but also results in
a far easier transition from there to fully authenticated,
compared to the massive gap between cleartext and fully
authenticated.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Oct 2013 16:24:12 -0400

> Thanks for the followup, identifying the CABF as the source of the key

I recently came across a document I wrote in 1999 arguing for 2048 bit
keys...

The problem that required CABForum intervention was that a 1024 bit key is
compatible with more browsers and always will be. Thus there is a
commercial advantage in using a 1024 bit cert so as to maximize the
customer base.

CAs were not prepared to stop issuing 1024 bit certs if doing so would lose
sales to a competitor. Browsers could not stop recognizing 1024 bit certs
as long as they were the majority of certs in use.

Agreeing to stop issue of 1024 bit certs (with some rare exceptions outside
the WebPKI) required both groups to make a mutual commitment.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 16 Oct 2013 23:08:07 +0200

* Nicholas Weaver wrote:
>We need universal protection against active adversaries, because the 
>precedents have been set and the distinction between passive and active 
>really is the willingness of the adversary to include active techniques.  
>We need end-to-end data integrity on all communication and if you have 
>end-to-end integrity, anything point-to-point rather than broadcast 
>should also include confidentiality since you can just about get it for 
>free by this point.

Adversaries do not necessarily have the resources to do anything they
are willing to do. Active attacks might require more expensive hardware
which they might not have the capital for, or they may increase latency
so that people get angry about them slowing down the Internet too much.

Authenticity and integrity are also sometimes at odds with other
desirable features like anonymity, deniability, and maintainability. In
some cases systems are not purely end-to-end, e-mail for instance also
has public discussion lists and newsletters with millions of subscribers
to consider.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mark Atwood <[email-masked]>
Date: Wed, 16 Oct 2013 17:21:13 -0700

| One reason is that these e-mail access protocols are used in
| enterprise environment where passive wiretapping often not
| considered a viable attack. Internal to the enterprise net there
| is usually a perception of adequate physical security.

I have discovered, in the last couple of months of investigation, to
my disappointment and horror, that many many very large IT shops in
the US that are doing telecoms between their various offices and
datacenters, do not encrypt.  Large telecoms users typically use MPLS
or telco provided "dark fiber".  Cleartext.  No encryption.  Not at
the wireline layer, not at the packet layer, and not at the
application layer.

The statement I get back when I have been investigating this is has
always been along the lines of "it's OUR glass" / "it's OUR circuit",
"it makes doing packet tracing and intrusion detection harder" (that
one makes me headdesk hard), "why should we be afraid of our telco
partner?", and "just because Google is doing it doesn't mean it's
useful to us".

I am working hard to assume ignorance and pollyanna-ism, instead of
malice and NSA-suborn-ism on the part of the CTOs and their security
people.

But anyway, that means that corporate use of Outlook & Exchange, Lync,
SAML, Intranet HTTP, SIP, remote file stores, IMAP & SMTP, remote
database access, remote backup, and internal customer and financial
records are completely transparent to the NSA, and to most every other
major spook agency in the world.  The NSA probably has a better view
into the second by second status of the health and wealth of the US
and world economy than any of the financial regulators.

..m

---

From: joel jaeggli <[email-masked]>
Date: Wed, 16 Oct 2013 23:09:25 -0700

> and world economy than any of the financial regulators.

MPLS VPN is more virtually private not virtual private. If you consider that the functional equivalent of your own wavelength or your own glass then maybe it's good enough for your purposes. from my vantage point none of those things are the tautological equivalent of an ipsec vpn

Wire-speed link-layer encryption is rather expensive at the feeds and speeds of modern routers. IP layer encapsulation in a ce-router in an MPLS hand-off is an expensive place to put it since that encryption complex is going on a asic in the fowarding path. For relatively slow links lots of these things are doable in a software forwarding engine… for 16 x 10Gb/s it's going to cost you.

operators and their customers make tradeoffs all the time, this is one of them.

http://www.safenet-inc.com/products/data-protection/network-wan-encryption/ethernet-encryption/

---

From: SM <[email-masked]>
Date: Wed, 16 Oct 2013 23:44:15 -0700

Hi Joel,
At 23:09 16-10-2013, joel jaeggli wrote:
>MPLS VPN is more virtually private not virtual private. If you 
>consider that the functional equivalent of your own wavelength or 
>your own glass then maybe it's good enough for your purposes. from 
>my vantage point none of those things are the tautological 
>equivalent of an ipsec vpn

[snip]

>operators and their customers make tradeoffs all the time, this is 

If I am not mistaken IP VPN has been sold over the years as a secure 
link.  That might have been good enough previously (see above about 
tradeoffs).  The threat evolves over time.  I am not thinking about 
state-sponsored surveillance here.  The tradeoff seems to be that the 
link is secure as it is private.

Regards,
-sm

---

From: Scott Brim <[email-masked]>
Date: Thu, 17 Oct 2013 07:52:43 -0400

> If I am not mistaken IP VPN has been sold over the years as a secure
link.

"IP VPN" includes not only MPLS VPN but also e2e IPsec. Also the meaning of
"secure" has been diluted down by marketing.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Oct 2013 10:12:29 -0400

Mark,

I've long referred to non-crypto VPNs as "virtually" private nets, for the
reasons you note. More cluefull enterprises do use encrypting firewalls for
inter-site protection. Cisco, Juniper, Checkpoint and others have made a
fair amount of money selling devices for this purpose.

When  alluded to remote access by employees, I was thinking along the lines
of road warriors, using IPsec or SSH tunnels for remote access.

I don't think we've seen any evidence to suggest that NSA is 
eavesdropping on
inter-site enterprise comms, at least for U.S companies, based on the 
Snodwen
docs released (so far).

Steve

---

From: joel jaeggli <[email-masked]>
Date: Thu, 17 Oct 2013 07:36:00 -0700

On Oct 16, 2013, at 11:44 PM, SM <[email-masked]> wrote:

> If I am not mistaken IP VPN has been sold over the years as a secure link.

It doesn't take a lot of sophistication to understand that putting a new header on the outsside and whacking an lsp on something doesn't make it secure in the encryption sense. when you still use the inner ip header as a hash for flow distribution across trunks, that ought be a reminder that you're a label strip away from an ip packet.

Regarding marketing, I hear that beer makes me smarter and cigarettes more sophisticated as well.

>  That might have been good enough previously (see above about tradeoffs).  The threat evolves over time.  I am not thinking about state-sponsored surveillance here.  The tradeoff seems to be that the link is secure as it is private.
> 
> Regards,
> -sm

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Oct 2013 10:58:26 -0400

> Capability wise, there is nothing except cryptographic data integrity that prevents an eavesdropper from injecting their own traffic.  On HTTP, this enables redirecting the browser to an arbitrary…
The ability to effect active and passive attacks is not uniform, and 
often not equivalent,
at least not on a per link basis. An attacker may be able to listen to a 
satellite down link or
a fiber cable, but not be able to inject packets into these links. So it 
is not quite accurate
to assert that any adversary who can passively monitor (a link) can also 
engage in active attacks
(on that link). The general form of active attacks that we usually 
assume in IETF security assesments
are MITM, which may be very hard to effect, depending on the context.
> Similarly, at layer 2, absent significant protection in the switch, properly configured, both DHCP and ARP injection allows similar total hijacking.  There are no capability limitations of note for…
What constitutes "significant protection?"
> Thus it really is "will" as convenient shorthand: is the attacker willing to use this and chance getting caught if a subtle detector is actually looking for the signs of attack?
I think it is more than just a concern re being detected.
> We need universal protection against active adversaries, because the precedents have been set and the distinction between passive and active really is the willingness of the adversary to include ac…
I agree that adding confidentiality is almost free once you have 
accepted the costs of integrity.
There may be hidden costs, though, of the sort I mentioned earlier, 
e.g., reduced ability to effect
traffic engineering, load balancing, and debugging.

When you mention integrity do you mean integrity w/o authentication? To 
me that's reminiscent of
the Rocky and Bullwinkle ad cut-away about fan mail from a flounder. If 
a bottle containing a note
were securely sealed, then one might assume that it was afforded 
integrity. But without authentication,
we don't know which flounder sent the note, which seems unsatisfying. 
Integrity w/o authentication
is MUCH easier than authenticated integrity, but I worry that folks will 
misinterpret the security
they're getting, with unfortunate results.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 17 Oct 2013 08:14:36 -0700

On Oct 16, 2013, at 1:24 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> Thanks for the followup, identifying the CABF as the source of the key length change.
> 
> I recently came across a document I wrote in 1999 arguing for 2048 bit keys...
> 
> The problem that required CABForum intervention was that a 1024 bit key is compatible with more browsers and always will be. Thus there is a commercial advantage in using a 1024 bit cert so as to maximize the customer base.
> 
> CAs were not prepared to stop issuing 1024 bit certs if doing so would lose sales to a competitor. Browsers could not stop recognizing 1024 bit certs as long as they were the majority of certs in use.
> 
> Agreeing to stop issue of 1024 bit certs (with some rare exceptions outside the WebPKI) required both groups to make a mutual commitment.
> 

which is pretty much the point I was making in terms of citing it as expensive  for the operators and consumers , but necessary. As a content provider I would have continued to use 1024 bit keys  as long as was plausible because the computational hit is significant enough that caused us to swap in an entire new generation of hardware.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Oct 2013 15:23:15 +0000

> It doesn't take a lot of sophistication to understand that putting a new header on the outsside and whacking an lsp on something doesn't make it secure in the encryption sense. when you still use t…

Yeah. The term has been used for a variety of things, that are "virtually private" in various different senses. I've seen it used for phone networks to indicate that you can dial a short number ("It's a VPN, so you can dial 4903 instead of 7534903!"), for MPLS networks because you can move any protocol you want, even if it's not IP (that's the multi-protocol thing), for MPLS networks where RTT is guaranteed by an SLA (just like your corporate LAN). Maybe we need to invent a different word for a virtual private network that actually provides privacy.

> Regarding marketing, I hear that beer makes me smarter and cigarettes more sophisticated as well.

That's confusing cause and effect. It's not that cigarettes make you sophisticated, it's that it takes a sophisticated person to hold a fire in your mouth without getting burned. As for beer, I thought IETF meetings were about converting beer into specs.

Yoav

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 17 Oct 2013 08:47:47 -0700

> The ability to effect active and passive attacks is not uniform, and often not equivalent,
> at least not on a per link basis. An attacker may be able to listen to a satellite down link or
> a fiber cable, but not be able to inject packets into these links.

Thanks to an ability to spoof packets from a gazillion different locations, as long as they can inject a spoofed packet from ANOTHER link in time, they will still be able to do packet injection.  The attacker's point of injection needs to be closer (latency wise) on the network than the final destination of the packet, but thats usually a pretty easy constraint to meet.

> So it is not quite accurate
> to assert that any adversary who can passively monitor (a link) can also engage in active attacks
> (on that link). The general form of active attacks that we usually assume in IETF security assesments

If you are assuming MITM on a packet level rather than just an eavesdropper (man on the side), then it really is a full-active attack is just a matter of willingness to do so, since a full MitM can drop packets as well.

> What constitutes "significant protection?"

Configurations like this:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html

http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?sp4ts.oid=1827663&spf_p.tpst=kbDocDisplay&spf_p.prp_kbDocDisplay=wsrp-navigationalState%3DdocId%253Demr_na-c02609533-1%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken

for ARP, and similar configurations for DHCP.

For the wireless "LAN", the problem is even worse, unless you deploy something like this:
meraki.cisco.com/lib/pdf/meraki_datasheet_airmarshal.pdf‎

you have to assume that the attackers can do all sorts of fun things if they know the password/can authenticate, such as spoofing an AP and relaying traffic.

For both cases, this requires reasonably high end switches and almost invariably require that they be properly configured.   Thus it is foolish to assume, in developing and deploying protocols, that the network does NOT suffer from man-in-the-middle attackers, even when you are "just in the LAN".

> I think it is more than just a concern re being detected.

Why?  Since its clear that there aren't technical limitations on an eavesdropper becoming a full MitM in most cases, its really is only "does becoming a full MitM benefit me as an attacker vs any increased risk of detection".

> When you mention integrity do you mean integrity w/o authentication? To me that's reminiscent of
> the Rocky and Bullwinkle ad cut-away about fan mail from a flounder. If a bottle containing a note
> were securely sealed, then one might assume that it was afforded integrity. But without authentication,
> we don't know which flounder sent the note, which seems unsatisfying. Integrity w/o authentication
> is MUCH easier than authenticated integrity, but I worry that folks will misinterpret the security

You need full authentication of all data and communication, so sorry for being unclear.

---

From: [email-masked]
Date: Thu, 17 Oct 2013 07:51:26 -0700 (PDT)

> busted for these services.

Actually, it's exactly the opposite: Details from the article make it very
unlikely that tapping into IMAP sessions is a significant source of data here.
In particular, both the article and the source material make it very clear that
this is primarily about address book information and only secondarily about
actual message content. As I noted previously IMAP does not carry address book
information.

Additionally, there's the peculiar use of the term "inbox" rather than to email
messages in general. IMAP provides access to all folders, whereas protocols
like ActiveSync are used specifically to notify users of the presence of new
messages in their inbox.

And as I noted previously, the peculiarly isolated IMAP slide at the  end is
not evidence of anything because we lack context. For all we know it was
included as an example of a case where collection is particularly difficult.

> (Even were TLS busted for those

> and there could well be alternative explanations.

Explanations that appear to me to fit the available information a lot 
better than yours does.

> services still allow IMAP over 143 without STARTTLS in addition to

I doubt it, but even if such information were available it would be irrelevant
to the matter at hand. Once more you're failing to take into account how email
is actually deployed these days. For better or worse, email has seen a huge
degree of centralization: The overwhelming majority of email now resides on a
fairly small number of server farms. If your concern in protecting the accesses
done by the majority of email users, those are the servers that count, not the
one I have at home or the one operated by my (tiny) ISP.

The state of play for those servers is actually pretty easy to quantify, and
I'll do that in a followup message.

> and more secure.

More on this later.

> And note - I'm not saying this should've been

First of all, IMAP is a less than ideal example because if we were doing it
today it would almost certainly be cast as a web service, and in that case it
would simply be another thing in the https/http space.

But if you ignore that little detail, I don't think you're going to like my
conclusions of the lessons learned from IMAP in particular and email in
general. My conclusionare that that most of the time the right things to do
are:

(1) Define the service on two ports, one with SSL/TLS covering the entire
    session and the other with no SSL/TLS option at all. (This makes the secure
    variant easy to deploying on connection-terminating load balancers, 
    which I believe is one of the driving factors behind the use of port 993.)

    There are going to be a few cases, like protocols that inherently deal
    with nothing but highly sensitive data, where specifying the insecure port
    variant should not be done. But not many.

    In contrast, there are *no* cases where the secure port should be omitted.
    I don't care if the protocol as designed only transfers public information.
    Protocols have a way of being used in ways their designers did not intend.

(2) Use the DNS in some way to announce which port a specific server expects
    connections to be on.

(3) Specify client latching semantics as a means to detect downgrade attacks.

(4) Think very hard and carefully about how certificate naming issues should
    be handled, and make sure your specification of them is both clear and
    complete.

(5) Think very hard and carefully about allowed/required ciphersuites and
    specify that very clearly and completely as well. (It is unclear to me
    whether this can be done for various classes of protocols versus on a
    case by case basis.)

(6) Do not design your protocol so that compliant operation depends on the
    use of SSL/TLS extensions or ciphersuites that aren't readily available
    in the various widely used crypto frameworks. And if this means there's
    some ugly wart in the protocol, so be it. (Note that this doesn't mean
    you call for implementation of the hoopy perfect forward secrecy scheme
    du jour, only that you can't depend on it.)

    That said, I think an exception needs to be made in the case of
    ciphersuites that employ rc4. I think rc4 is sufficiently problematic
    that its use needs to be discouraged even though that may make
    compliance difficult or even impossible in some cases.

(7) Since there are going to be choices to make when deploying, document
    those choices and their consequences clearly.

(8) The current fixed security considerations sections we currently employ
    are inadequate given how rapidly this stuff evolves. The IETF needs to
    develop a means of formally amending security considerations with
    additional information without having to open the entire document up
    for revision.

(9) Keep the use of normative references for purposes of specifying
    security to a minimum. And if this means some repetition of material,
    so be it.

Conspicuous by its abence on this list is any mention of anything being 
mandatory to use, and as few things as possible that would translate into
something being mandatory to implement. This is because I think history shows
that these sorts of IETF pronouncements - in the email world at least - have
been about as useful as pissing into a strong wind.

More generally, persuasion beats being doctrinaire hands down. Not to toot my
own horn or anything, but since Internet email a la RFC 821/RFC 822 deployed
we've managed to make exactly one really substantive change stick on a more or
less global basis. That was MIME, and we did it without a single mandate that
it be used. Instead we made it as compeling as we possibly could and we also
bent over backwards to make it as easy to deploy as possible.

> are also presumably not IMAP related.

That would be where you said:

And as I noted above, you can't divorce them from inbox data collection nearly
as easily as you seem to think.

> and ensures that those are used (by not having the

See above. Again ignoring the fact that IMAP wouldn't be done in remotely
the same way if we were doing it today, the anwer is no, we'd almost
certainly still want to have an insecure variant.

> and end up with one version.

On the contrary, what's damaging on day zero is having a specification for
which compliance isn't practical for a significant fraction of implementors,
deployers, or both. This is what happened in the case of IMAP, and the result
was vendors ignored what the specifications called for and secured the protocol
in their own way. (And security isn't the only example of this in IMAP.)

> I don't get what you mean there.

You claimed that there are valid arguments that the TLS ciphersuites that are
MTI are too hard to deploy. AFAICT that claim is false.

> against other bad actors.

Because given the way email actually works this may well be a case of putting
bars on the barn windows while leaving the door unlocked.

> you yacketed about address books above for example.)

You need to reread your own original message as well as the material in the
slides before making any such claim.

> problem for mail in general. (Some others on this list are more

You're still not answering the question, at least directly, and I really want a
direct answer. More expensive for whom? The vast majority of current and likely
future email users, who seem perfectly happy to use the service offerings of
large ISPs and MSPs? If so, then any proposal you come up with needs to done in
a way that persuades those providers that making changes to their service
offerings is the right thing for them to do.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Oct 2013 22:53:37 +0100

Some bits snipped out...

> actual message content. As I noted previously IMAP does not carry address book

So you're interpreting "inbox" to mean address book. To be
honest, I'm not convinced by that.

That's not how I read it - I do interpret inbox to mean
inbox, primarily mail accessed via imap or webmail.

> included as an example of a case where collection is particularly difficult.

I agree it stands out from the others and is hard to interpret.
I don't think inbox is hard to intepret at all though.

> one I have at home or the one operated by my (tiny) ISP.

Protecting the majority of email users is not the same issue. Its
also a fine thing but slightly different, see the end.

> general. 

I don't dislike 'em actually. Most seem reasonable.

> My conclusionare that that most of the time the right things to do
> are:
> 

That's the bit I'm questioning. I figure that if we could do
just the secure one, then we'd be done and that'd be a better
approach than having two. I also think that if we muck up and
do a pretend job on security then we end up with 3: plain,
pretend-secure and eventually-fixed-secure. That's happened
with more than IMAP.

I don't know if only doing the secure one in an IETF context
is at all likely though. History would seem to show that its
not. OTOH, it is true that doing the secure versions is much
better understood now and much more practical than it was a
decade ago, so I think its worth exploring.

>     variant should not be done. But not many.

Yep. And some cases like DHCP where its just hard to do
meaningful (crypto) security.

>     security to a minimum. And if this means some repetition of material,

I think I'd agree with almost all of (2)-(9).

> been about as useful as pissing into a strong wind.

I agree about pronouncements. But I also think we might be able
to do better than we're doing now without 'em.

> as easily as you seem to think.

As per above. I don't find that convincing.

> certainly still want to have an insecure variant.

Why? Serious question.

> in their own way. (And security isn't the only example of this in IMAP.)

I agree that that happened and was damaging. I don't thinks its
at all contrary to what I said.

> MTI are too hard to deploy. AFAICT that claim is false.

I do think that the PKI parts are too hard to deploy. Not for
the larger MSPs, but it could be a good bit easier. Or maybe
you're the one person in the universe who thinks that deploying
PKI is a doddle:-)

> direct answer. More expensive for whom?

Ah sorry. I think the goal here is to make pervasive monitoring
more expensive for anyone (govt or other) who wants to do that,
in cases where we think we can create a maybe significant enough
disencentive, but without making things harder for people who're
using protocols as designed. There will be some tradeoffs there
for sure, but in some cases if we get consensus for changes then
we might actually improve things for the normal users too.

The first part of that is new to the extent that we're dealing
with a new threat model. If we can do something for that, then
my hope is that we can improve general security and usabiliy as
well, since we've learned a good bit about that (or should have)
in the last decade.

> The vast majority of current and likely

That's fair.

S.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Oct 2013 17:45:04 -0700

On Oct 17, 2013, at 7:51 AM, [email-masked] wrote:
> Stephen Farrell <[email-masked]> on Oct 15, 2013 5:31PM wrote:

Dear Ned,

Improving the efficiency of email acceptance might be this incentive.  As IPv6 becomes pervasive, an authenticated domain source as a basis is likely to be more sustainable over time.  Establishing expectations that StartTLS confirms both server and client certificates affords improved transactional protection from spoofing or reputation poisoning, especially with the transparency and economy afforded by DANE for protection from simple monitoring, malicious spoofing, and reputation poisoning.  Providers will need to be trustworthy and may need to reside in specific geopolitical regions willing to ensure such protections.

Multiple keying of encrypted data where each key subset resides in different geopolitical regions might be a way to increase trust, but this is not off-the-shelf crypto which you state as a requirement.

Regards,
Douglas Otis

---

From: Randy Bush <[email-masked]>
Date: Fri, 18 Oct 2013 07:50:27 +0300

> "IP VPN" includes not only MPLS VPN

the vpn without a p

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Oct 2013 18:00:28 +1300

On 10/18/2013 12:52 AM, Scott Brim wrote:
> On Oct 17, 2013 2:45 AM, "SM" <[email-masked] <mailto:[email-masked]>>
> wrote:
> "IP VPN" includes not only MPLS VPN but also e2e IPsec. Also the meaning
> of "secure" has been diluted down by marketing.

The words "secure" and "security" have long lost any technical meaning. 
  Today they are useful only as umbrella terms as referencing an area of 
effort, not an actual capability.  So "working on security" rather than 
"producing security".

Unfortunately, 'privacy' also lacks any serious technical meaning, since 
even the IAB was not willing to define it in their RFC.  Hence the term 
means whatever the speaker wants it to mean, which might not be what the 
listener understands it to mean.

So if someone wants to assert the presence or need for some sort of 
security-related functionality, they need to use terminology that is 
universally understood to be precise.

For this thread, I suspect what is mean is IP-layer Confidentiality, 
which is e2e only if the application layer doesn't have any hops, where 
the content will be in the clear during the relaying.  Like with email 
MTAs, or Web caches...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 18 Oct 2013 06:49:02 -0400

> like ActiveSync are used specifically to notify users of the presence of new

Disclosures about inboxes and individual messages were part of earlier revelations/declassification:

https://www.eff.org/document/october-3-2011-fisc-opinion-holding-nsa-surveillance-unconstitutional
https://www.eff.org/deeplinks/2013/08/intelligence-agency-attorney-explains-how-multi-communication-transactions-allowed
https://www.cdt.org/blogs/alissa-cooper/1109nsa%E2%80%99s-laziness-masquerading-reasonableness

Alissa

---

From: [email-masked]
Date: Thu, 17 Oct 2013 15:11:07 -0700 (PDT)

> honest, I'm not convinced by that.

Of course I'm not interpreting it that way. Inbox has a very specific
and well defined meaning in email - the place where messages are delivered
to the user by default - and I'm using that definition.

> inbox, primarily mail accessed via imap or webmail.

Of course that is what it means. But I'm starting to wonder whether or not
we're reading the same article. There's only one reference to acquisition
of mail message content in the one I'm reading, which says:

  Each day, the presentation said, the NSA collects contacts from an estimated
  500,000 buddy lists on live-chat services as well as from the inbox displays
  of Web-based e-mail accounts.

I'm not going to bother quoting the correponding material on the actual slides
because I'd have to retype it, but it absolutely backs up this paragraph.

Clearly the inbox information is coming from web mail. And the way modern web
mail works is a big wad of Javascript gets  downloaded to the browser, which
then communicates with the back end server by exchanging JSON, XML, HTML,
whatever with a back end server. The client state, to the extent there is any,
is jointly maintained by the front and back ends.

The web mail server (which may consist of multiple server layers, proxies,
caches, separate authentication servers, and who knows what else) then talks to
the actual message store. In many cases this is done in a proprietary fashion.
And if IMAP is used, those IMAP connections are happening within the data
center, not on the open Internet. Even if the connections travel from
one data center to another (the use-case for that would be shared folder
access, which by definition is not going to be your inbox), that's going
to be done on a private network, if for no other reason than to avoid timeout
issues.

And as I noted before, ActiveSync may play a role here, although I'm not
familiar enough with the use cases for it to be sure.

> I don't think inbox is hard to intepret at all though.

It isn't. But you appear to have not considered the context in which it was
used.

> pretend-secure and eventually-fixed-secure. That's happened

It's not what happened with IMAP. We specified one mechanism with real
security, but included enough weasel words that engaging that security was not
required. But the mechanism we specified failed to meet deployability
requirements in the real world, and as a result a plurality if not an actual
majority of what actually deployed was a secure mechanism we did not specify.

> decade ago, so I think its worth exploring.

And the reason it is not is that there are compelling reasons to provide
the variant without security.

> Why? Serious question.

Because of things like usage inside of data centers, where all the connections
are either protected physically or by encryption at a different layer. Indeed,
there are use cases where security auditing mandates that SSL/TLS *not* be
used.

Now, of course you can argue that this is some sort of private use case that
doesn't warrant coverage in the relevant standards. But I'm here to tell you
that this sort of handwaving is increasingly being seen for what it really is:
A refusal to come to grips with how applications are implemented and deployed
at very large scale. And it doesn't help when we also botch the secure variant
we do specify.

> at all contrary to what I said.

I don't know what "contrary" means in this context. That said, it is my
position, based on decades of dealing with the major players in this space,
is that what you are proposing will at best be ignored and at worst be even
more damaging.

> you're the one person in the universe who thinks that deploying

The way the PKI part of this plays is that there's an initial pain point
getting it going and, for a large data center, automating certification
generation and distribution. But this is a one time cost, and not a substantial
one.

More generally, you don't seem to grasp the way a setup with 10s of millions of
accounts with services scattered across hundreds, thousands, or even tens of
thousands of hosts has to operate. In such a world the automation of 
certificate generation and distribution is an insignificant detail buried
inside of a vast amount of other automatic configuration processig.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Oct 2013 22:22:02 +0100

Hi,

On 10/17/2013 11:11 PM, [email-masked] wrote:
> ...I'm starting to wonder whether or not

The slides eventually linked to are at [1], slide 4 bullet 2
is the main one I think but you're right that the first bullet
says webmail. My assumption is that they use every possible
way they can, whether that's webmail or IMAP or IM or whatever
goes by in clear or more probably some combination.

[1]
http://s3.documentcloud.org/documents/804763/a-sso-content-optimization-detailed-redacted.pdf

> is jointly maintained by the front and back ends.

Thanks for web-mail-101 lesson;-)

> to be done on a private network, if for no other reason than to avoid timeout

Sure. But with 4.7M listeners on port 143 (see my earlier mail) it
would be credible too to get a bunch of those via installations
that don't have a working starttls setup.

Mind you the above speculations aren't really decideable so its
probably not worth our time to quibble further on it.

> It's not what happened with IMAP. 

I didn't say the above was a blow-by-blow description of
how we ended up with IMAP. But we did end up with 3 flavours
as described.

> We specified one mechanism with real

That's consistent with what I said above.

> there are use cases where security auditing mandates that SSL/TLS *not* be

That's not inconsistent with the default being to include and
turn on security from day 1. Things can also be turned off for
scenarios such as the above, so I still don't see a need to
have specs that only cover the insecure/plain version of things
like IMAP.

My point is that if we took that approach then we'd be far
less likely to screw up the security bits, for performance,
deployment or "too much" security reasons or whatever reason
your undoubted experience tells you is most common.

> that this sort of handwaving is increasingly being seen for what it really is:

You put words in my mouth and then accuse me of handwaving?
That makes it hard to have a discussion on what is I think
an important topic. (How to screw up less with how we define
security for our protocols.) It'd be better maybe to tone
that kind of thing down a bit.

> I don't know what "contrary" means in this context. 

You said "on the contrary" - I don't think we're disagreeing
much.

> That said, it is my

I'm getting the impression you think I'm proposing something
I'm not, but its quite hard to tell really.

S.

---

From: [email-masked]
Date: Sat, 19 Oct 2013 14:48:02 -0700 (PDT)

> Improving the efficiency of email acceptance might be this incentive.  As
> IPv6 becomes pervasive, an authenticated domain source as a basis is likely to
> be more sustainable over time.  Establishing expectations that StartTLS
> confirms both server and client certificates affords improved transactional
> protection from spoofing or reputation poisoning, especially with the
> transparency and economy afforded by DANE for protection from simple
> monitoring, malicious spoofing, and reputation poisoning.  Providers will need
> to be trustworthy and may need to reside in specific geopolitical regions
> willing to ensure such protections.

I must be missing something here, because I don't see how what we've been
discussing - preventing pervasive surveilance in general and mandating
SSL/TLS on more connections in particular - has anything to do with email
acceptance.

> Multiple keying of encrypted data where each key subset resides in different
> geopolitical regions might be a way to increase trust, but this is not
> off-the-shelf crypto which you state as a requirement.

The security of IMAP and similar mailbox manipulation protocols seems 
entirely divorced from what you're talking about.

				Ned

---

From: Douglas Otis <[email-masked]>
Date: Sun, 20 Oct 2013 15:45:58 -0700

Dear Ned,

Good questions. See comments inline.

> SSL/TLS on more connections in particular - has anything to do with email

This is achieved by StartTLS exchanging BOTH client and server certificates.  While indeed security concerns are normally related with destinations of account access over web, IMAP, and POP where the client is authenticated using other means, it is important not to overlook the lack of privacy protection afforded plaintext exchanges over SMTP.  Internet exchange in plaintext is exposed to undetectable surveillance not requiring any provider cooperation.  Deprecating use of plaintext exchange for what should be considered "private" user-to-user communications would force governments and providers to use expressed policies.  Any plaintext exchange should be considered "public" especially when warrantless wiretapping has become the norm since 2007 with legal clarifications suggesting "information gathering" is not "electronic surveillance".  This can lead to Orwellian concerns of "self censorship" through various forms of suppression and ostracism.

Private exchanges should be able to use encryption as the prevalent mode for all exchanges.  With SMTP, encrypted exchanges immediately confront a lack of source authentication necessary to defend the service from pervasive abuse.  With IPv4, a lack of source authentication is supplanted by reliance on the IP address as a basis for acceptance.  This practice has many drawbacks such as preventing the effective use of IPv6 that could be remedied by validating the client certificate used in what would have been a plaintext port 25 exchange and its related loss of privacy.

> entirely divorced from what you're talking about.

Almost.  There are some delivery schemes that do not depend upon privacy protections afforded by the infrastructure.  For example, Trend acquired an identify based keying product developed by the University of Bristol back in 2002.  Here is a white paper created by the Enterprise Strategy Group.
http://www.trendmicro.com/cloud-content/us/pdfs/business/white-papers/wp_true-costs-of-email-encryption_analyst-esg.pdf

It uses Identity Base Encryption (IBE) a derivative of PKI, but with simple identity attributes.  Rather than depending on CAs, Central Trust Authority (CTA) is used instead.  Because destination addresses decode the symmetric key, only that portion of the message is uniquely encrypted.  This allows one image to be sent to several destinations where only those intended to see the message are able to decrypt.  This approach allows enterprises a means to inspect for data leaks to comply with governmental requirements not practical with S/MIME or OpenPGP unless key management and encryption has been centralized.  As such, this means a portion of the message path could be exposed.  After speaking with the developer of this technology, one of the features envisioned from this approach was to require the use of multiple CTAs each located in different geo-political regions to prevent any unilateral governmental action defeating message privacy.

If there is any interest in this technology, perhaps I could then request my management share its terms and conditions and more of the underlying details.

Regards,
Douglas Otis

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Oct 2013 08:38:21 +0200

> compared to the massive gap between cleartext and fully

Teasing out OE from other potential tasks is a good thing; of that I'm
convinced.  Whether it's more than MTI *or even MTI* depends on what
recommendations can be made regarding how to do it.  A draft there would
be most welcome (I've heard that some are thinking about doing something
with OTR).

Eliot

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Oct 2013 11:58:06 -0400

Nicholas,
> Thanks to an ability to spoof packets from a gazillion different locations, as long as they can inject a spoofed packet from ANOTHER link in time, they will still be able to do packet injection.  T…
If I understand the attack, it requires wiretapping to determine the TCP 
sequence numbers and window
info to create an acceptable response, then send a packet to effect the 
redirect. When you factor
in the latency constraint, it's not clear that there are "a gazillion 
different locations" for
an active wiretapper to use, relative to a wide range of possible targets.
> If you are assuming MITM on a packet level rather than just an eavesdropper (man on the side), then it really is a full-active attack is just a matter of willingness to do so, since a full MitM can…
Sorry that I was not clear in my comment. What I was saying is that we 
usually view a full, MITM
capability as representing a active wiretap capability, and that is NOT 
the assumption on which
the attack you noted is based. Thus I was arguing that the full MITM 
capability may be much harder
achieve, vs. a passive capability. Also, given the asymmetric routing 
common for many Internet paths,
it might be hard to be a MITM, or a passive wiretapper, for both 
directions of a session, unless
one is able to be very close to one end of the session.

Your discussion of what it takes to securely configure LAN switches, and 
WLANs does
not convince me that its easy for an adversary to gain access, or, 
conversely, that it's
very hard to manage LANs and WLANs to address the cited vulnerabilities. 
That does not mean
that I assume all LANs will be well-managed in this regard, but it's a 
big jump from
"sloppy LAN management" to "easy to effect a MITM" attack on most 
enterprise LANs.

Over the weekend i checked with a friend who consults on security 
matters to a number of large firms,
principally in the financial services and related industries. He 
confirmed by earlier comments re use
of encryption within enterprise LANs. It is almost non-existent, and the 
IT folks want to keep it
that way. They do not see credible passive wiretapping threats in their 
nets, and they value ease of
monitoring and debugging more that the incremental security offered by 
adding encryption. (They're big
on authentication and integrity, just no confidentiality measures within 
a LAN.)

> Why?  Since its clear that there aren't technical limitations on an eavesdropper becoming a full MitM in most cases, its really is only "does becoming a full MitM benefit me as an attacker vs any i…
You have asserted that it's easy, but I don't agree with a number of 
your arguments, so
I'm not ready to concede that becoming a MiTM is easy in many cases.
> You need full authentication of all data and communication, so sorry for being unclear.
OK, glad we agree on that point.

The problem many of us see is that it's much easier to perform 
opportunistic encryption,
that does not provide authentication, than to provide authentication 
with encryption.

Steve

---

From: [email-masked]
Date: Wed, 23 Oct 2013 10:49:35 -0700 (PDT)

> about how many have a usable STARTTLS config.

But more to the point, the same study found 3.9M listeners on port 993. And
these days most clients try 993 first and only then fall back to port 143.
Assuming that everyone offering port 993 also offers 143, this would indicate
that at least 83% of IMAP servers out there are capable of being used in a
secure fashion. Which I have to say is a lot better than I expected.

But as I indicated previously, when it comes to addressing pervasive
surveilance of large numbers of users, even if we restrict ourselves to the
IMAP space this sort of survey is completely meaningless because if fails to
take the number of users on a server into account. My home server, with its
whopping total of 3 IMAP users is almost certainly on that list under two IPs,
and so is another server I know of, also under just two IPs, that hosts around
100 million users.

According to The Radicati Group, the ISP/MSP space is dominated by software
produced by folks like Critical Path (Intermail), Openwave Messaging, and yes,
Oracle (Oracle CMES). Now take a look at where these products rank on the
list you cite.

Like it or not, the email world is hugely lopsided and getting even more so as
an increasing number of small ISPs and enterprises migrate to hosted
solutions in the cloud. This growing concentration is both a curse and a
blessing: On the one hand, it means that a single exposure, like the fact that
Yahoo's webmail doesn't offer SSL/TLS even as an option (and is almost
certainly a major source of the information collection we're talking about
here). But on the other hand, when Yahoo implements SSL/TLS on their web mail,
as they have now said they are going to do in 2014, a major exposure will be
blocked.

Now think what a benefit it would be if SMTP traffic between Gmail, Apple, and
Yahoo was all done over encrypted links.

> With that

That number is credible coming just from Yahoo web mail, which we know is wide
open and which we know they were collecting because it's referenced directly on
the slides. You *really* need to start thinking on a larger scale here.

Some additional information about the state of web mail showed up in
SANS Newsbites the other day:

  --Yahoo Webmail Gets Default SSL Protection in January
  (October 14, 2013)
  Yahoo has announced that starting on January 8, 2014, all Yahoo mail
  will be protected by SSL by default. Microsoft has offered optional SSL
  protection since 2010 and it has been default for Microsoft webmail
  since July 2012. Facebook implemented SSL for all connections several
  months ago; it has been an option since 2011. Twitter offered it as an
  option at the beginning on 2011 and made it default by August of that
  year. Google has had SSL on by default since 2010, an option since 2008.
  Yahoo began offering the option of SSL encryption earlier this year.
  http://www.washingtonpost.com/blogs/the-switch/wp/2013/10/14/yahoo-to-make-ssl-encryption-the-default-for-webmail-users-finally/
  http://news.cnet.com/8301-1009_3-57607486-83/yahoo-mail-finally-turns-on-ssl/
  http://www.theregister.co.uk/2013/10/15/yahoo_mail_encryption_by_default_in_2014/

> of IMAP and MTI is still worth thinking about.

Not along the lines you seem to be considering.

				Ned

---

From: [email-masked]
Date: Wed, 23 Oct 2013 11:30:10 -0700 (PDT)

> use of SSL to protect IMAP/POP access.

It is almost certainly the case that large ISPs and MSPs are what's being
targeted, because, to paraphrase the quote falsely attributed to Willie Sutton,
"That's where the data is".

So perhaps we should, you know, take a closer look at the current state of play
in this space. Given the relatively small number of players this isn't
all that difficult. 

For my testing I used a client that supported the following ciphersuites:

  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  TLS_DHE_DSS_WITH_RC4_128_SHA (0x0066)
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
  TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  SSL_RSA_WITH_RC4_128_MD5 (0x0004)
  SSL_RSA_WITH_RC4_128_SHA (0x0005)
  TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
  SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff)
  SSL_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  SSL_CK_RC4_128_WITH_MD5 (0xff01)
  SSL_CK_RC2_128_CBC_WITH_MD5 (0xff03)
  SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (0xff07)

As most people are probably aware, the way SSL/TLS works is the client
proposes then the server selects the ciphersuite to use. The client I'm
using lets me enable whatever ciphersuite set I want, so when the server
selected something less than stellar I used this capability to see if I could
force a better result.

I mostly tested large MSPs and North American ISPs, but I tried a few European
and Australian ones as well. I attemped a few Asian and Middle Eastern
sites, but setup directions written in scripts I don't understand proved to
be too much of an obstable.

Anyway, the results are as follows:

1and1.com - imaps and imap, imap allows starttls
   imap.1and1.com - TLS_RSA_WITH_AES_256_CBC_SHA
     no DHE variants available

Apple: imaps only
   imap.mail.me.com - SSL_RSA_WITH_RC4_128_MD5,
     SSL_RSA_WITH_3DES_EDE_CBC_SHA if RC4 disabled,
     TLS_RSA_WITH_AES_256_CBC_SHA will be used if only AES ciphers allowed,
     no DHE variants available
     
AOL: imaps and imap, imap allows starttls
   imap.aol.com - TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
     TLS_DHE_RSA_WITH_AES_256_CBC_SHA available
   
Cox Cable: imaps only
   imap.cox.net - TLS_RSA_WITH_AES_256_CBC_SHA, no DHE variants available

Charter: imaps only
   mobile.charter.net - TLS_RSA_WITH_AES_256_CBC_SHA,
     SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA available
   
Covad: imaps and imap, imap allows starttls
   mail.covad.net - TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
     TLS_RSA_WITH_AES_256_CBC_SHA if Camillia disabled
     no DHE variants available

Eastlink: imaps and imap, imap allows starttls
   mail.eastlink.ca - TLS_RSA_WITH_AES_256_CBC_SHA, no DHE variants available

free.fr: imaps and imap, imap w/o starttls
   imap.free.fr - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  
GoDaddy: imaps and imap, imap allows starttls
   imap.secureserver.net - TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
     TLS_RSA_WITH_AES_256_CBC_SHA if Camillia disabled,
     no DHE variants available

Gmail: imaps only
   imap.gmail.com - SSL_RSA_WITH_RC4_128_SHA,
     TLS_RSA_WITH_AES_128_CBC_SHA if RC4 disabled, no DHE variants available

GMX Mail: imaps and imap, imap w/o starttls
   imap.gmx.com - TLS_RSA_WITH_AES_256_CBC_SHA
     no DHE variants available

Hotmail: imaps only
   imap-mail.outlook.com - TLS_RSA_WITH_AES_128_CBC_SHA,
     no DHE variants available

iinet: imaps and imap, imap allows starttls
   mail.iinet.net.au - TLS_RSA_WITH_AES_256_CBC_SHA
     TLS_DHE_RSA_WITH_AES_256_CBC_SHA available

Insight Communications: imaps and imap, imap allows starttls
   mail.insightbb.com - TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Internode: imaps and imap, imap w/o starttls
   mail.internode.on.net - SSL_RSA_WITH_RC4_128_MD5
     SSL_RSA_WITH_3DES_EDE_CBC_SHA if RC4 disabled,
     TLS_RSA_WITH_AES_128_CBC_SHA if only AES ciphers allowed,
     no DHE variants available

Namesco: imaps and imap, imap w/o starttls
   imap.hosts.co.uk - TLS_DHE_RSA_WITH_AES_256_CBC_SHA

neuf.fr: imaps and imap, imap w/o starttls
   imap.neuf.fr - TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Optus Broadband: imaps and imap, imap allows starttls
   mail.optusnet.com.au - TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
     TLS_DHE_RSA_WITH_AES_256_CBC_SHA is Camilla disabled

telefonica.net: imap w/o starttls
   imap.telefonica.net

tre.it: imap w/o starttls (8 year old server software!)
   imap.tre.it

Yahoo: imaps and imap, imap requires starttls
   imap.mail.yahoo.com - SSL_RSA_WITH_RC4_128_SHA,
     TLS_RSA_WITH_AES_128_CBC_SHA if RC4 disabled,
     no DHE variants available

Videotron: imap w/o starttls
   imap.videotron.ca

Notes:

(1) Verizon, Comcast, Netzero, Earthlink, Mindspring, Sprint (?),
    Shaw Cable, lightspeed.ca, Cogeco, Time Warner Cable,
    CableVision(OptimumOnline) (?), Bigpond, and Mediacom do not support IMAP
(2) AT&T?, Rogers Cable use Yahoo for IMAP
(3) Cable One, Telecable uses gmail for IMAP
(4) The presence of Camellia as an option is explained by the fact that in
    NSS if Camillia is enabled at all it is used preferentially. (Although
    maybe not in the case of Optus Broadband.)

Keeping in mind that this is hardly a comprehensive list of the world's ISPs,
I'll first note that the ciphersuite situation is better than I expected. A
minority of services, albeit some of the biggest ones, prefer RC4. And nobody
insisted on it. Quite a few even go so far as to prefer a DHE variant. But more
of them need to support and prefer something in the DHE/AES set. This is a place
where some clear guidance would probably be helpful, as long as it involves
using ciphersuites for which support is readily available. (The obvious starting
point is for servers to always prefer AES to RC4 and always prefer DHE variants
to non-DHE variants. I'll the ranking of those two to those more pedantic than
I.)

Only three of the services tested, one in North America and the others in
Europe, offered no SSL/TLS at all. That strikes me as pretty good coverage
overall, and perhaps the Snoden revelations will make something good happen to
those, as it is doing at Yahoo.

But these results, while encouraging, don't say anything good about the IETF's
ability to mandate security. The IETF recommended best operational practice
(effectively a SHOULD in RFC 3501) is to only offer port 143 and require
STARTTLS on that port, as indicated by the LOGINDISABLED capability. Not a
single provider I tested implemented that specific variant. Not. One.

The closest was Yahoo - you know, the folks whose web mail has no security at
all - which does operate port 143 that way, but they also offered the
nonstandard imaps on port 993. Five services, including most of the largest
ones, offered the nonstandard imaps only. An equal number offered imaps but no
SSL/TLS capability on port 143. (These results are explained by the use of load
balancers that act as the termination point for SSL/TLS.)

Anyway, I've spent enough time on this, but if anyone else wants to throw
additional results for large ISPs and MSPs my way, especially from places using
scripts I don't grok, I'd appreciate it.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Oct 2013 23:38:40 +0100

Hiya,

> Keeping in mind that this is hardly a comprehensive list of the world's

Quite useful though. Thanks.

> I'll first note that the ciphersuite situation is better than I expected. 

Ditto.

> to non-DHE variants. I'll the ranking of those two to those more

Any voluneteers? Might be close enough to fit in the smtp/tls
draft Alexey said he'd look at.

> single provider I tested implemented that specific variant. Not. One.

Yep. I agree that's a problem. Seems we disagree about the
conclusion to be drawn though. For me, the above indicates
that our current "make 'em specify a MTI (in the RFC6919
sense)" failed in this case.

I conjecture that had there been a more-than-MTI practice in
place way back then, its a good bit more likely we'd not have
screwed up on the TLS stuff. And so I figure its worth
investigating that some more. (Not for IMAP, but in general
for current/future work.)

S.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 24 Oct 2013 05:24:35 +0000

> Define "nobody," please. Microsoft Lync uses SIP/TLS by default. That must

And it used by the other nobody, Cisco 

I realize it may be less common on service providers private  networks but the carriers assume they have adequate protection for the attacks they care about just by controlling who has access to the private network. 
 
The only reason I mention this is that some people do read our stuff, read our security sections, and try to make a rational decision. The rational decisions for many places that Cisco and Microsoft PBX's deploy is to turn on TLS. The rational decision after reading the security sections we wrote for the service provider private networks may actually be to not use TLS. (note I'm not arguing private networks are private, or that firewalls work, or anything like that - I'm say that people make have thought about the security and decided they had adequate protection against the attacks they cared about - which to be clear were probably toll fraud and not confidentiality of the media )

A threat models change, deployments do to. I'm pretty confident more than a few business are rethinking the threat model of how much nations state grade attackers might be sharing data with their competitors, or do that in the future, and what they might do about that.

---

From: [email-masked]
Date: Wed, 23 Oct 2013 19:53:28 -0700 (PDT)

> sense)" failed in this case.

It absolutely did fail, but because we screwed up and specified the wrong
thing. It absolutely escapes me how you can believe that putting a stronger
mandate for the wrong thing would have helped. The far more likely
result would have been more confusion and a overall poorer outcome.

What happened instead was both implementors and deployers of the technology did
the right thing IN SPITE OF OUR HAVING SCREWED UP. A "let's give implementors
and deployers even less leeway in the name of better security" change hardly
seems to be justified by these events.

> for current/future work.)

OK, if I understand you correctly, you're saying that had we demanded more back
then, we would have done a better job. Since I was there at the time and
remember the arguments and decisions quite well, it's easy to demonstate that
this conjecture does not stand up to any sort of analysis.

I first note that the main reason SSL/TLS was on the table was to protect 
passwords, not to protect entire mail sessions. The latter was a "nice to
have", not a "must have".

Nevertheless, the concern over password protection was serious. But there was
also serious concern that whatever was specified would be both implementable
and deployable. That concern was focused on clients - it was felt that the
number of combinations and permutations clients had to deal with needed to be
kept to an absolute minimum or client implementors wouldn't support any of it.
(This concern seems ridiculous now in light of the large number of IMAP
extensions that have specified since then and the resulting combinatoric
explosion that clients have to deal with.) 

On the server side, there was little if any concern expressed over
deployability at large scale. There was some concern expressed over export
restrictions. (Remember that this was happening in 1999-2002 and all this stuff
was in a state of flux.)

And then there was the feedback we were getting from the security area. We
were being told:

(1) Having any sort of clear text mechanism was bad, because there was
    tremendous skepticism that SSL/TLS would actually be deployed to
    protect password exchanges.

(2) Two port solutions are bad. If you're going to use SSL/TLS, it needed to
    be negotiated inband.

(3) GSSAPI/Kerberos was the path of truth and righteousness for password
    protection. There was reluctant acceptance that DIGEST-MD5 could be
    used, but not CRAM-MD5.

As a result of all these competing interests, what got specified was that
password needed to be protected and therefore it was mandatory to implement
either STARTTLS/PLAIN, DIGEST-MD5, or GSSAPI. Which was hardly a recipe for
interoperability. Rather, it was a reflection of the fact that we just didn't
know what the right solution was.

And at that point we got really, really lucky: Four separate IETF screwups
conspired to make the right thing happen: (1) DIGEST-MD5 was a total faiure,
(2) GSSAPI was seen as undeployable, (3) The negotiated one port solution for
SSL/TLS was undeployable, and (4) Our assessment of what implementors would be
willing and able to do was wildly incorrect.

Given this backdrop, I don't think a claim that demaning more security would
have led us to the correct two port SSL/TLS solution is remotely credible. Had
that happened it is *far* more likely we would have mandated DIGEST-MD5
support. But even if we'd moved in the SSL/TLS direction it would have
been a one port approach.

Of course if we were doing this now we wouldn't make the same mistakes. What
we'll do intead is make a great big bunch of new ones. Indeed, that is already
happening: See Paul Hoffman's recent message about how attempts to increase
SSL/TLS security is conspiring to lower its use in the field.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Oct 2013 18:35:15 +0100

Hiya,

On 10/24/2013 03:53 AM, [email-masked] wrote:
> we'll do intead is make a great big bunch of new ones.

Thanks for sticking with it. I now realise where we disagree.

I do think we've learned enough in the interim that we'd be
likely to get how to use TLS much closer to right for something
like IMAP today.

I don't doubt that we'll find lots of ways to make mistakes as
well of course, I just don't think they'd be in that area.

Cheers,
S.