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.
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?
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.
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.
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) as a club to justify encryption in all transport protocols.
This does not bode well.
Increasing the cost to the "attacker" means increasing the costs to the
implementer and to the user, and to the designers, far more. 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.
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