On Wed, Feb 8, 2012 at 9:35 PM, Nico Williams <[email protected]> wrote:
E-mail is not an online protocol between two MUAs. When you send an e-mail your MUA is not talking directly to the recipient's MUA, and there are no automated replies except for vacation replies.
That last assertion is demonstrably false. Among other things, there's the "return receipt requested" processor. There's the "mailing list distribution autoresponder". There is what I'm developing, which is exactly what I'm talking about. Email acceptance by an MTA does not have a divine right to a reply. But if it does merit one, wouldn't it be nice for the remote to be able to opportunistically encrypt it with knowledge of our security capacities? Remember, the only thing that we can ultimately rely on is that a public key identifies its own and only its own private key. We can use that to our advantage, if we stop worrying so much about MitM at the cryptography layer and instead present the "you might not be speaking only to who you think you're speaking to, someone else might be listening in, so don't say anything that you want to keep private" MitM possibility elsewhere in the UI.
Thus in a cold-call e-mail send you have no knowledge about the recipient's MUA's capabilities. You can only sign your e-mail and hope that the recipient can validate the signature.
A cold-call email is a special case. The initial reply isn't a cold-call email. nor is any reply after that. Neither is any further communication with that endpoint. It is absurd that we're letting the special case become the enemy of the good. "We assume that because it's not presently possible to query public registries for email keys, the entire model and concept is crap." This is another instance of the binary "completely utterly blindly correct" or "it's not worth the bits it's encoded in", and it's as harmful here as it is in the browser security model. We must fix the security model here, not push the burden onto application designers who have neither guidance nor expertise in the field.
If you know the recipient's public key and can derive some knowledge about the recipient's MUA's capabilities from that public key and surrounding material, such as a certificate or other metadata, then you can send signed and encrypted e-mail to them.
There is metadata associated with every email. It exists in the form of headers. These headers identify, among other things, the MUA the sender is using. There's no reason this can't be extended. (In fact, extending it is encouraged!) If the sending MUA includes (for example) an EC public key and notes that it supports ECDH with Sha128 or Sha256 key derivation and Aes128 or Aes256, there is no certificate involved so there's no fear. The recipient MUA can see that public key in the header, and it can generate its own EC public key to include in the header of the reply -- which has been encrypted with the ECDH-derived shared value as the key. We must permit this kind of opportunistic, unauthenticated encryption, because email is far too important to leave plaintext. We must accept that Alice has absolute right to put whatever she wants in her messages, and she can engage in any activity she wants to do to figure out what it's going to be. We must accept that Bob has the absolute right to do whatever he wants with any message he receives, no matter its content. We must plan for when Bob doesn't want to abide by Alice's security policy, by making the system depend on copyright exercise (which includes the exclusive ownership of the right to derive a shared key from a public key). We must plan for when Alice sends something to Bob that breaks our narrow-minded interpretation of the rules, and present it as something other than full-stop "this isn't something I (software) recognize, so I not only won't let you do it, I'll scare you away from it." We must plan for when Bob sends something with a clickwrap license that Alice doesn't want to accept. If we do it right, we enforce that the derivation of the shared key is subject both to Alice's policy (by deriving the shared key to send with) and Bob's otherwise-unilateral imposition of policy. This makes the participants peers in the conversation, not one master and one slave. The required
metadata -the recipient's MUA's capabilities- are found where the recipient's public key is found. That metadata has to be somewhere, but e-mail headers isn't that somewhere.
Not right now. I believe it should be, because... This limits your and your
correspondents' ability to switch to other MUAs: they'd better support the capabilities that you've advertised with your keys.
...more correctly, they'd better support the capabilities that my CA has advertised with my key, and I'd better not change my client to something with different capabilities or lose the private key (which, in keeping with security extremism, I have created in a piece of hardware such that I can't export it -- meaning that as soon as the hardware dies, I've lost the key). If I change clients, or heaven forbid have multiple clients with different capabilities, I require the cooperation of an external entity, which is a commercial enterprise charging me for that cooperation.The common insistence on "must be authoritative CA" operates in the real world as nothing more than a railroad into a racket. This is why a header is necessary. It is the least motion which must be made to enable opportunistic encryption. (The alternative is allowing self-signed S/MIME certificates, that the client software creates itself. I don't know that people would really like to accept self-signed certificates without a way to leverage the existing CA infrastructure and its authoritative identity assertions.)
Sure, we could build a TLS-like protocol out of e-mail, if MUAs knew how to speak to each other the mail network.
They do. The packet is called a message, the transport is called "the MTA network". The packet arrives in substantially unchanged form at the destination via a reception protocol such as IMAP or POP3. You'd say you want to
send e-mail to [email protected] and your MUA could send a specially crafted e-mail that Joe's MUA understands as a ClientHello (and which Joe wouldn't see, as it would do Joe no good to see it), responding with ServerHello and so on, and then you have a session key that you can use to send encrypted mail to Joe.
Have you not heard of Diffie-Hellman? Or Elliptical Curve Diffie-Hellman? This is a mathematical transformation which allows two independent private key holders to arrive at the same value using one's own private key and the other's public key, based solely upon one exchange of public key material. There's no need, reason, or desire for a full ClientHello TLS negotiation, and focusing on the handshake to the exclusion of what the technology actually permits is an astoundingly unintelligent idea. This is another problem, people involved in the processes who don't know what the cryptography actually allows for so they can't comprehend when their rules are harmful. And then we'd need to
negotiate cipher suites and such just like TLS. But that's not how e-mail works. You send an e-mail, and hopefully it gets there, and there's no automatic ping-pong until keys are established, there's only that one e-mail.
Wow. From this description, one would think that the recipient MUA didn't have the power to parse headers, send via SMTP, or keep track of the parameters that were sent with any given message or from any given sender. One would also think that it was impossible for automatic mail processors to exist, like remailiers. Your point is misapplied, it's much more suited to Usenet than email. Usenet implies "I'm posting something for anyone to read". Email implies "I'm sending a communique to someone with whom I want to engage in dialogue." The special case of "cold call email" is much, much less common than the common case of "mail to a colleague or someone with a pre-existing relationship". Getting hung up on the special case has prevented solutions for the common case. Our job is to specify interoperability standards, not to inflict our personal horizons on the utility of the standards we come up with. (Put another way: Just because a standards designer can't comprehend why a client legitimately and validly needs a particular capacity doesn't mean that the standards body has the right or responsibility to prohibit it in their output.) So. You send a quick query signed with a throwaway uncertified key to the intended remote, via SMTP. The recipient MUA receives that message, parses it, and then sends (via SMTP) a self-signed key encrypted to the public key you queried with. This is accomplished with information in a header which MUAs already parse, such as From:, Replies-To:, and Errors-To: headers. If we do it right, we don't have to disclose the sender's or recipient's identities, even to each other -- while still obtaining the benefits of strong authentication and accountability in the network. Right now, it relies upon the disclosure of email addresses. I have a design which doesn't even need that.
That's why S/MIME and PGP work the way they do.
That hangup is also (one of the reasons) why S/MIME and PGP haven't caught on. (For more, see below.) S/MIME and PGP rather missed much of the point, because everybody in OPGP-WG and PKIX-WG have been too hung up on what other people say identities are. That hang-up has caused these security technologies to be unacceptably useless in the real world. There is no recognition (beyond lip-service in OPGP) that the person is his own ultimate authority, and can choose to accept anything he wants even if it doesn't meet the standard's concept of "acceptability". Societies don't have reputation because they need identity, they have identity because they need reputation. A person legitimately has many more reputations than just the ones labeled with the label the state uses, and a person legitimately has a need to issue credentials within his own domain. This means that there exist legitimate reasons to snub the authoritative Certification Authority industry, especially given standard protocols that permit assertions from one and only one chain of authority. There are reasons why
S/MIME and PGP haven't become killer apps (and someone who knows much more about them than I can lay them out), but lack of a header by which to communicate MUA capabilities is not one of them -- we would have solved that long ago if it had been.
I mentioned one reason above. Others are: 2) the artificial and unnecessary terror induced by misguided-by-IETF implementors who present untrusted chains as somehow less secure than no signature at all. 3) the lack of transparent operation, it's another step in the rote process of getting set up that people don't plan time for. 4) The exhortation in PGP's documentation to keep your private key on a single medium, with no provisions for what to do if that medium is lost. If you (like me) had your private key on a floppy disk way back when, you probably (like me) lost it to bad sectors at some point, and (like me) lost access to information encrypted to it. If we can't guarantee that the user data will be accessible, it's not secure. 5) The authoritarian model which PKIX-WG has improperly assumed fits reality, when in reality society is much more democratic with its petty fiefdoms. 6) The inability of people to play around with ASN.1-based authentication technologies without feeling like every time they clicked the "sign" button they'd just somehow sold their firstborn, again due to the misguided-by-IETF implementors who inflict terror in their user interfaces. The idea that unauthenticated cryptography is useless is false. Among other things, it enforces that attacks on the privacy of the content have a minimum work factor which must be surpassed. In the real world, this means that a state would actively have to attempt to attack a person with an MitM email relay. This is certainly doable, but I don't think it's something that we can really prevent. In addition, even non-authoritarian regimes have legitimate law-enforcement needs to intercept communications. And even then, once authoritative certifications or external-channel fingerprints are exchanged, it could be detected and its utility would be severely limited. The idea that "Self Assertions are Null Assertions" is false. Self-assertions permit the person, the Self, to communicate information that they say about themselves, rather than solely what other people have said about them. The idea of providing only a single certificate chain is bad, because it even limits the information a person can put forth to what -one- other person has said about him. The worldview that SAaNA spawned has stifled the advancement of incremental, effective, useful cryptographic technology. The indoctrination into the "certifications are the only way to know you're talking to who you think you're talking to" worldview begs the question, "do we always need to know precisely who we're talking to?" And I assert the answer is no. If it were yes, we wouldn't have unencrypted HTTP going over the network. The mandate to only ever grudgingly permit Absolutely Correct semantics to be presented without UI failure prevents effective application of transparent, opportunistic cryptographic implementations with effective on-ramps into Authoritative Semantics. Thus is the indoctrination of the PKI Priesthood. Peter Gutmann (U. of Auckland NZ) has referred to this indoctrination as "PKI me harder". To make the world a better and more secure place, it must be shaken. -Kyle H
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
