Hiya,
On 10/23/2013 07:30 PM, ned+perp...@mrochek.com wrote:
Keeping in mind that this is hardly a comprehensive list of the world's
ISPs,
Quite useful though. Thanks.
I'll first note that the ciphersuite situation is better than I expected.
Ditto.
A
minority of services,
On Oct 17, 2013, at 10:51 AM, ned+perp...@mrochek.com wrote:
Hiya,
Many snippets below...
On 10/15/2013 07:13 PM, ned+perp...@mrochek.com wrote:
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
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
Hi,
On 10/17/2013 11:11 PM, ned+perp...@mrochek.com wrote:
...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
On Oct 17, 2013, at 7:58 AM, Stephen Kent k...@bbn.com wrote:
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),
Some bits snipped out...
On 10/17/2013 03:51 PM, ned+perp...@mrochek.com wrote:
Hiya,
Many snippets below...
On 10/15/2013 07:13 PM, ned+perp...@mrochek.com wrote:
Following up on my own point - not stylish but I think
in this case justified:-)
On 10/15/2013 12:41 AM, Stephen
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?)
On Oct 16, 2013, at 8:23 AM, Stephen Kent k...@bbn.com 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
At 05:47 14-10-2013, Tony Rutkowski wrote:
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.
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
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
On Oct 15, 2013, at 1:26 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
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
see why we shouldn't be equally comfortable in saying don't
send
* Stephen Farrell wrote:
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
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
On Tue, Oct 15, 2013 at 10:44 AM, Tony Rutkowski
rutkowski.t...@gmail.comwrote:
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.
One problem is that the traitor in question
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)
On 10/15/2013 05:21 PM, Phillip Hallam-Baker wrote:
On Tue, Oct 15, 2013 at 10:44 AM, Tony
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
Joel,
On Oct 14, 2013, at 8:01 AM, Ralf Skyper Kaiser sky...@thc.org wrote:
Hi,
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
On Oct 15, 2013, at 1:49 PM, Stephen Kent k...@bbn.com wrote:
Joel,
On Oct 14, 2013, at 8:01 AM, Ralf Skyper Kaiser sky...@thc.org wrote:
Hi,
I understand the goal of making life harder for state surveillance.
However, I am not willing (personally) to incur any degraded user
Steve,
On 10/15/2013 07:03 PM, Stephen Kent wrote:
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
Hiya,
Many snippets below...
On 10/15/2013 07:13 PM, ned+perp...@mrochek.com wrote:
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
see why we shouldn't be equally comfortable in saying don't
send
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
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,
* Stephen Kent wrote:
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
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
Hi,
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
Since you alluded to some MTU above, the obvious question is what are
examples of
MTU mechanisms that you support?
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
On 10/14/2013 03:43 PM, Stephen Kent wrote:
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 requires it.
To first order, we're
On Oct 14, 2013, at 8:01 AM, Ralf Skyper Kaiser sky...@thc.org wrote:
Hi,
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
Ralf,
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
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
Hi,
I understand the goal of making life harder for state surveillance.
However, I am not willing (personally) to incur any degraded user
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
, 2013 12:33 PM
To: Ralf Skyper Kaiser sky...@thc.orgmailto:sky...@thc.org
Cc: perpass perpass@ietf.orgmailto:perpass@ietf.org
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
Hi Steve,
On 10/14/2013 06:39 PM, Stephen Kent wrote:
Stephen,
...
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
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
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.
On Wed, 9 Oct 2013 09:28:38 -0400
Moriarty, Kathleen kathleen.moria...@emc.com wrote:
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
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
] 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?
On 10/09/2013 11:44 PM, Peterson, Jon wrote:
A BCP could
however provide the necessary motivation for using TLS
Ben,
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.
Amen! But, I so rarely see that attitude among vendors.
In short, be
Hiya,
On 10/10/2013 07:49 PM, Stephen Kent wrote:
Stephen,
Well, MTU vs MTI is not quite what the subject line says, but is
clearly one of the options worth discussing.
I thought that was the focus, based on the subject line. Sorry.
Partly my fault, but I reckon there should be more options
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
Hay,
Hiya,
I...
I disagree. IMO all the snowdonia stuff is very good evidence that
we need to do better. And enforcer is not at issue.
Can yo be more specific here? I have not examined all of what is being made
public; I do have a day job :-) .
And the 2nd. But the 2nd is a case where
hi Brian, all,
On Oct 9, 2013, at 1:02 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
On 09/10/2013 11:23, Peterson, Jon wrote:
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
On 8 October 2013 22:14, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
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
, 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
Ben,
O...
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
On 9 October 2013 16:55, Stephen Kent k...@bbn.com wrote:
Ben,
O...
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
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
Ben,
...
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.
That does not seem to be uniformly true. Some folks who purchase
equipment have been know to
On 9 October 2013 18:33, Stephen Kent k...@bbn.com wrote:
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).
Ben, please stop pushing CT as
Ben,
Sorry if I misinterpreted your comment in this context.
Steve
...
Ben, please stop pushing CT as the solution for everything; it's become
more than tiresome.
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.
On 9 October 2013 18:33, Stephen Kent k...@bbn.com wrote:
Ben,
...
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.
That does not seem to be
, 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
On 10/09/2013 11:44 PM, Peterson, Jon wrote:
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.
I'm confused by that a bit - given the GCHQ/Belgacom example, in
which
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
On 10/10/2013 12:21 AM, Peterson, Jon wrote:
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,
I agree with that.
and that
security is IMO worse and defo much more of a PITA.
S.
-Original Message-
From: perpass-boun...@ietf.org [mailto:perpass-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Tuesday, October 08, 2013 7:13 PM
To: Peterson, Jon; perpass
Subject: Re: [perpass] mandatory-to-implement vs
Hi Steve,
On 10/09/2013 06:22 PM, Stephen Kent wrote:
Stephen,
Thanks for creating a new thread to discuss this topic. It's a good
starting point for
an important discussion.
I agree its important.
I think MTU (vs. MTI) is a very hard argument to make, for several reasons,
some of
-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 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.
-- Christian Huitema
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
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
On 09/10/2013 11:23, Peterson, Jon wrote:
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.
How about
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
: 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
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
66 matches
Mail list logo
