[Cryptography] upgrade mechanisms and policies

[ianG]

On 19/04/2015 02:56 am, Jerry Leichter wrote:
> On Apr 16, 2015, at 5:59 PM, ianG <iang at iang.org> wrote:
>>> I mean, for instance. Do you think this email should be encrypted, or
>>> simply authentificated?
>> These emails should be un-auth, moderated and encrypted.
> This answer actually contradicts the rest of your point, which comes down to:   You can't make sensible security choices without considering the entire system.

Indeed.  I was speaking to what I think we want, not what I think we can 
do easily.


> This is an open mailing list.  Anyone can ask to join, and will receive all the messages.  Given that ... encryption is pointless.  The list itself acts as an oracle for any encryption done on the list!

Entirely.  But it is a cryptography list.  If there is anywhere that 
should be able to do an encryption list it is here.

Actually the encrypted list is something that is often demanded of 
groupware software, and it is a well-known hard problem.  Normally this 
is helped a bit by closing off the access to ones group, but this 
doesn't help the fact that too many holders of the secrets is too 
brittle.  Forwarding, backups, local hacks and all that.


> As for authentication, for one thing, there are (at least) two possible kinds of authentication for messages here:  Of the original author, and that the message actually came through the list forwarder.  One can easily construct scenarios in which the presence or absence of either of these is desirable, and the two are independent of each other.

Indeed.  But take the well-known case of SSL.  The industry bends over 
backwards to state that authentication of the server is the key benefit. 
  Yet, they fail to authenticate the server in phishing - a simple 
bypass attack.  And for most webservers, they couldn't care less about 
their own authentication, what they care about is the client 
authentication.  SSL completely muffs client authentication, leaving the 
users to come up with ad hoc password stuff.

(Yeah, now poeple will chime in and repeat the marketing about how it's 
hard because of multiple devices and and and ... the point is, every 
which way you look at the SSL story, it isn't about what the users need, 
it's about what was easy to convince to be sold.)


> And even if authentication of the original author is desirable - that covers a huge piece of ground.  Would you want to bind the identity of this message to my passport - one extreme - or merely to previous messages - on this list?  In this response stream?  Anywhere on the Internet? - sent with the same apparent identity?

Well no.  I said un-auth.  Specifically, my threat here is in an unknown 
time and place in the future, during hot crypto wars II, my comments on 
this list are taken as evidence that I'm an international arms dealer. 
I don't want to be auth'd on this list.


> Simple point-to-point communication between parties who have some external way of identifying each other is the easy case.  Everything else is harder - sometimes *much* harder.


Even simple point-to-point communication is hard, because of that 
additional rider.  And if we factor out email, which is practically 
insecurable (handwavy opinion) there isn't another robust Internet p2p 
communications mechanism that is open and distributed.



iang