email encryption
22 points by binjip978
22 points by binjip978
Today, the relevance of the OSI protocols is limited to the frustrating insistence of modern networking textbooks on trying to explain the internet in terms of the "OSI model," a now more speculative than actual layer model that describes a different system incompatible with the internet.
i'm sure a lot of people are aware of rob graham's osi deprogrammer, but for today's lucky 10000...here you go.
Yeah, and don’t miss the link to the earlier essay by ~jbcrawford on the actual OSI model.
Readers might also enjoy my commentary on the two articles.
highly recommending your article (it actually came up before rob's when searching for it, so i cribbed the link in the comment above from yours :^) )
I loved your commentary, thank you. My main takeaways:
I'm still not sure how to differentiate a protocol from a protocol's layer? That is, it seems like layers themselves are protocols— or if they aren't, they often grow into one.
At this point, I considering protocols as a path through a graph rather than a layered stack.
It’s important to distinguish between a protocol suite (such as OSI) and individual protocols (such as X.25). In the OSI model a layer can be instantiated by one or more specific protocols.
Protocol suites are sometimes designed in layers, but note the paragraph towards the end where I wrote about protocol modules such as MIME and SASL, which are a notable feature of internet application protocols that doesn’t fit a layering model.
Other things that aren’t layered are (for instance) BGP and DHCP which configure IP but are carried on top of IP, instead of being implemented as control messages that are underneath or alongside IP (which is how they would have been designed in OSI style). Er, perhaps a better illustration is OSPF vs IS-IS, which are both intra-AS routing protocols often used to configure IP, but OSPF is an Internet-style protocol that runs on top of IP, whereas IS-IS is an OSI-style protocol that runs underneath IP.
One point I didn’t mention is that protocol layers usually correspond to syntactic encapsulation: for example an ethernet frame contains an IP packet contains a TCP segment contains a TLS record. Protocol layering is often taught in abstract terms like, a layer provides a higher-level service (eg, global addressing / streams / encryption) but that tends to make programmers think in terms of OO design when they ought to think of framing / chunking / wrapping accompanied by a smattering of control messages.
Oh, another thought: I wrote about ethernet’s sublayers, but I didn’t explicitly point out that ethernet has grown to become a protocol suite in its own right, with a bunch of its own control protocols (starting with the spanning tree protocol and growing in complexity from there).
For example, the encoding of X.400 messages is ASN.1, a binary serialization format that is more efficient and capable than MIME but also a lot more complicated.
I recently learned from Harald Alvestrand’s Canonical Internet vs X.400 Debate that MIME does content-type much better than X.400, in particular the pages on
The main thing this article misses out is PEM, privacy-enhanced mail which is notable because it introduced base64 (before MIME!) and the “-----BEGIN OBJECT-----” … “-----END OBJECT-----” encapsulation that is still used for keys and certificates. Well, PEM gets a few mentions but I think it deserved more to elucidate the influence from X.400 and X.500 and the ways that parts of PEM were re-used in S/MIME. My guess is that PEM and MIME didn’t work neatly with each other because they have different ways for representing encapsulated messages, so S/MIME was developed to re-do PEM as part of a more general-purpose framework.
This did indeed come out kind of weird. My original intent was only to cover the present-day email encryption landscape, thus the decision to not expand on PEM besides noting that it's the origin of the base64 encoding and certificate format. But then the article came out about twice as long as I intended and covered a lot more of the history, so I think that turned out to be the wrong decision.
Thanks for writing such an interesting blog!
Yeah it’s hard to make sense of such a mess when the only rational explanation comes from all the historical mistakes and mis-steps.
Another thing I can’t clearly remember (or didn’t really understand at the time) was the extent to which PGP avoided the existing standards because they were unobtanium, or deliberately steered clear because of government export restrictions and RSA’s patents. (I was surprised to see that many of the ITU’s standards (such as ASN.1) are now openly published; I don’t know when that happened.) In many ways PGP was a deliberate “fuck you” to all the militarized restrictions on encryption, including RSA inc. who were an enthusiastic participant. So I guess they wouldn’t have used the X.400/X.500/PKCS flavoured standards even if the specs had been available.
There were a lot of shenanigans in the open source world to work around these issues, beyond “this t-shirt is a munition”: for instance, FreeBSD had a second source repository hosted in South Africa for its export-controlled crypto code. I briefly worked for a company that sold a version of Apache-SSL linked to (iirc) the rsaref library instead of ssleay/OpenSSL, so that it had a proper patent licence in the USA. In principle, the open source projects that were not directly involved in the campaign to lift the restrictions tried to only import cryptography to the USA (which was allowed) but it’s best not to enquire too closely into how well they maintained that hygiene.
.jpg){kind=link}