How is that doing? What's the status of the ability to connect to a CDN without revealing to the network which CDN customer you're talking to?
Is there still a new DNS RR for communicating ECH public keys along with IP addresses?
For context: one of the long-standing problems with TLS was and still is the fact that it leaks a lot of metadata. You could say that it's a chicken and egg problem. To encrypt anything you first need to agree on the parameters, which happens during the handshake. TLS 1.3 improved things a lot by encrypting all server handshake traffic that can be encrypted, but a lot of metadata remained in plaintext. That information can be used for client fingerprinting, for example.
Among other things, website name is transported in the clear, in the Server Name Indication (SNI) extension. This is a problem if you want to access a particular website but don't want, say, the authorities to know.
This problem was discussed during the development of TLS 1.3, but didn't make the cut. However, development continued afterwards, with the first attempt being Encrypted SNI. That work eventually evolved into ECH. More powerful, but also more complicated. The basic idea behind both ESNI and ECH is that websites can announce public keys for clients to use to encrypt data even on the first flight. As the name says, ECH is designed to encrypt the entire ClientHello (the first message in a TLS handshake.) ESNI relies on a custom DNS TXT record, but ECH uses the new SVCB DNS RR https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... (which is interesting for a couple of other features, for example to use as an indication that a website is HTTPS-only).
Cloudflare have been working on ESNI and ECH. Here's one good blog post where they go into detail about how it all works: https://blog.cloudflare.com/handshake-encryption-endgame-an-...
We saw with the rollout of CAA that it's actually kind of challenging to add new DNS RRs because a lot of DNS implementations are hard-coded to block ones they don't understand, even though the DNS standards tell them not to do that. So I'm a bit worried that a lot of DNS services will have a hard time with SVCB records for a long while.
I guess having SVCB queries get dropped (or return false negatives or spurious errors) would be catastrophic for the ability to negotiate via ECH, since then the client won't know the key, but not catastrophic for the ability to negotiate a TLS session at all (since you can still fall back to CNAME and A/AAAA records in this case).
Encrypted Client Hello is still named Encrypted Client Hello, as of https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.txt
It's not really true that "it keeps getting renamed" the original intent in ekr's draft was to encrypt SNI, but then the question is why not encrypt other things in the client hello, and if you're going to then why not encrypt the entire client hello?
There isn't really room for further scope increase, the server hello was already encrypted in TLS 1.3 anyway.
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an... https://news.ycombinator.com/item?id=28103770
Only something like Apple Private Relay or Tor can solve that issue.
I hope services setup a "ech.fqdn" endpoint that forces ECH and doesn't work without it. Something like "encrypted.google.com" from before https was so popular.
E.g. "ech.facebook.com", or "ech.youtube.com"
On a positive note, I was able to add "PKI" to the title, which makes sense because the book is actually about PKI as much as it is about TLS. A win-win, I think.
TLS 1.3 is definitely a good breaking point. If you understood exactly how SSLv3 works, you could read TLS 1.2 and say to yourself OK, this is basically the same protocol except with some fresh paint and with some extra gadgets I needn't care about yet, whereas you just can't do that with TLS 1.3.
I also see you put TLS 1.3 first, and I think that's a good choice, show people the Right Thing™ as we understand it today first, this is not a history lesson.
I feel that in many situations the solution for IoT PKI is to find a good vendor who will support you, and there's plenty of those around to choose from.
If you have a moment, I would appreciate if you could share some more specific questions, and perhaps your use cases. That will help me understand if it's something I can cover in a future update. That said, the book is already quite big at 500 pages.
I suppose my biggest gripe is that it has been hard to find sources of best practices. Almost everything I find is amateurish/not designed to scale or white papers designed to sell services. Or when I encounter best practices, they are too vague to be actionable.
Without mutual authentication you won't be able to authenticate the devices themselves. Perhaps you intend to have a different mechanism, perhaps sign the messages? I feel that signing the messages would provide better security guarantees as the signatures will accompany the data.
I think the most important aspect to get right is to have the ability to update the root material. No matter what CAs you end up using, their roots will eventually expire and will need to be replaced. Clearly, you don't want to lose the root material as that would be catastrophic. Using two separately managed roots would probably be a good idea.
AWS and Google have private CA services, and EJBCA is also worth exploring, for example: https://doc.primekey.com/ejbca/solution-areas/iot-and-device...