Hi Lloyd,
(dropping httpbis, Mark asked to reduce their noise level
yesterday)
On 12/06/2013 06:42 AM, l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk wrote:
My argument is that security (confidentiality and encryption in
transmission) should always be _optional_ in a transport protocol.
Define a NULL cleartext ciphersuite if you have to, but do make
cleartext transmission possible.
That is a good discussion to have, but isn't necessary or relevant
for this draft, which itself doesn't specify nor mandate any
particular mitigations. I think you're attacking a wrong target.
With the analogy with DRM, encrypting everything didn't work there.
Why should it work here? What is gained, apart from a lot of
overhead?
There is a difference - with DRM, the user is considered the
adversary, in this case the adversary (in protocol terms) is
often a third party.
But yes, there are pervasive monitoring situations where the
adversary might be the service provider, but those are to some
degree outside the IETF's remit for now, except where we have
good e2e security options. Unfortunately, in many cases we do
not yet have good enough e2e security options that can be
deployed at Internet scale to handle such cases. But we should
continue to work at that. A case where we can provide e2e would
be XMPP, where OTR is a good proof that you can provide some
e2e security and the XMPP WG are working away at a standards
track e2e solution. (And separately some folks are writing up
an I-D on OTR I think.)
We are not however going to stop sending email just because
neither S/MIME nor PGP are good enough. And this draft won't
mean that anyone making such an argument (e.g. that we should
all use S/MIME all the time) will be able to use the resulting
BCP to force their wishes on an unwilling world.
What this BCP (when published) will do is ensure that someone
who has a good technical option doesn't have to re-litigate
the argument that pervasive monitoring is an attack that we
should mitigate.
Allowing encryption to be optional:
- increases the chances of base interoperability.
- increases the chances of debugging problems in the field.
- increases the chance of the protocol even being implemented,
or being implemented and used where the threat model does
not require confidentiality or encryption as a response.
- makes lightweight implementations possible, which can scale
down to be fit for purpose.
In the context of a discussion of whether the IETF should
move beyond mandatory-to-implement, (MTI) I would argue
each of the above. But, that's not this discussion.
draft-farrell-perpass-attack notes: "the IETF is not equipped to
tackle the non-technical aspects of mitigating pervasive
surveillance"
Well, yes. RFC2804 deliberately passed on the moral position of
wiretapping surveillance, while draft-farrell-perpass-attack is
appealing to vox populi as its argument. We're not even capable of
articulating why pervasive surveillance is bad. We're just reacting
to news reports.
We are quite properly reacting to newly presented and relevant
facts. Even if we don't have a full picture of all the facts,
its unquestionably the case that we have enough real information
to justify taking action.
Frankly, I don't think the IETF is well-equipped to tackle the
technical aspects of mitigating pervasive surveillance either. I
don't see evidence of that to date.
I do not have confidence that the IETF can do good security protocol
design together with good transport protocol design. My fear is that
the two will be combined into one by using
draft-farrell-perpass-attack and its followons (hey, BCPs get
updated)
BCPs only get updated after IETF last calls.
as a club to justify encryption in all transport protocols.
This does not bode well.
Fear not! Again, if your fear is of "more than MTI" then that is
not part of this draft but is a separate discussion.
Increasing the cost to the "attacker" means increasing the costs to
the implementer and to the user, and to the designers, far more.
"far more"? I disagree. The high cost of using crypto was a fine
argument to make 20 years ago, but for almost all systems that's
no longer the case.
And if you look at the work e.g. Tero did for IPsec with no
certificate handling, (which I think is being documented in lwig)
its quite possible to do the crypto in very tiny devices. Doing key
management securely is harder in such such environments though
that is true, and would be something that relevant working groups
would take into account.
It
means increasing the complexity of the specification and
implementation. It's complexity beyond what can be handled in
committee. draft-farrell-perpass-attack can be considered an attack
on IETF transport area work for those reasons. It's going to have
more of an effect on the IETF than it will on the NSA.
I think that's nonsense fwiw. I suspect Lloyd and myself
won't have a meeting of the minds on the topic though;-)
S.
Now, this isn't to say that the IETF shouldn't try to design secured
protocols mitigating snooping for users - when there are actual users
and use cases, and a threat model that requires consideration of
privacy. It should not be an indiscriminate blanket effort. But when
an attempt fails to achieve that impossible goal of a secure protocol
free from monitoring (and it will fail), having a transport protocol
that still useful and workable in the clear once all of the
has-been-found-to-be-broken-by-design-before-being-obsoleted
security-stuff is stripped away is still an achievement. And that
transport can still carry data encrypted at a higher layer. Which is
what e.g. TLS is for...
Lloyd Wood http://sat-net.com/L.Wood/
sure, you're speaking for security. Who is speaking for transport?
________________________________________ From: Hannes Tschofenig
[hannes(_dot_)tschofenig(_at_)gmx(_dot_)net] Sent: 04 December 2013 18:38 To:
Wood L
Dr (Electronic Eng); ted(_dot_)lemon(_at_)nominum(_dot_)com Cc:
perpass(_at_)ietf(_dot_)org;
bruce(_at_)perens(_dot_)com; ietf-http-wg(_at_)w3(_dot_)org;
ietf(_at_)ietf(_dot_)org Subject: Re:
[perpass] Commnets on draft-farrell-perpass-attack-00 was RE:
perens-perpass-appropriate-response-01
Hi Lloyd,
On 12/04/2013 10:55 PM, l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk wrote:
I see you ignore the DRM point.
I don't understand your DRM point to be honest. It also does not seem
to be relevant to this conversation. DRM standards have not been
been developed in the IETF either.
draft-farrell-perpass-attack-00 does not specific solutions (which
it states in the document).
If your argument is that security adds complexity to protocols then
that's certainly true. The other option would be not to have security
in protocols at all to make them "more lightweight". Do you seriously
think that this is useful option (even before the NSA revelations)?
If your argument is that security problems on the Internet should be
solved via legal / regulatory ways then please go ahead an make
these proposals. Obviously, the IETF would be the wrong forum to do
that. I am sure the European Commission, for example, is interested
to listen to your proposals and will immediately issue new proposals
for regulation. It would be great if those you think that there are
regulatory solutions would in fact then work on those rather than
just having technically minded people who push problems around.
If your argument is aging cryptographic algorithms require software
to be updated then let me tell you that software gets updated even
for functionality reasons. Do you think that all the software updates
you get for you smart phone apps are only security fixes? There are,
however, many software updates that relate to security
vulnerabilities. My approach would, however, be to incorporate
software update mechanisms into products (which is what pretty
everyone in the industry seems to be doing) instead. While this is
largely a non-IETF issue it would still be interesting to hear
whether you have other suggestions.
Your suggestions to do more interoperability testing sounds
reasonable to me. I have been involved in interoperability tests
myself (and even organized a few). Those tend to have a different
focus, namely to provide feedback about whether the implementations
interpreted the specs correctly. Penetration testing is what you
would typically do to discover security vulnerabilities. We typically
don't do those (at least not that I have heard). As such, I would
rather seen them as a orthogonal effort (which many in the IETF are
involved in already anyway). Are you suggesting that we should also
do penetration testing?
Please also note that "security" is not a monolithic block, as you
can see from RFC 3552. In various discussions with you I got the
impression that you dislike security in general. That can hardly be
true since I am sure you like some of the security features in there
as well. For example, you might find authentication a pretty cool
concept to avoid others accessing your email account.
Ciao Hannes