<div dir="ltr">Greetings to the distinguished Veterans, my Upperclassmen, and Grand Elders,<br><br>We built an end to end verifiable chain for e-mail, and I want to share four things to this list specifically.<br><br>You can verify it: <a href="https://bmail.ag/verify">https://bmail.ag/verify</a><br><br>1. Operator Trust<br><br>Every hosted service/SaaS since both before and after the crypto wars has required trust in the operator. In e-mail, particularly, this has not bore the best of results.<br><br>- Hushmail decrypted and handed over confidential data.<br>- Lavabit had to seppuku since a single key would have resulted in handing over confidential data. I salute you, Mr. Levison.<br>- Tutanota complied with a german court order to quietly perform a backdoor op.<br>- Proton logged a climate activist's IP<br><br>The cryptography in each system was likely solid (despite some better choices in architectural design that could have taken place). However, the common denominator in each is that they included a "trusted operator."<br><br>Operator trust is the single weakest link.<br><br><br>2. Attestation + Reproducible builds<br><br>Intel's SGX DCAP allows a server to prove which binary is running as it is signed by a chain rooted at Intel. Further, when compiled byte for byte reproducibly, you can build it yourself locally to verify it is the same. This creates a unique level of transparency and, contrastingly, privacy.<br><br><br>3. DANE<br><br>The honorable tptacek famously argued the falacies of DNSSEC's verification model insofar that it concentrates power in TLD operators/registrars, and said TLD/registrars answer to governments. On its own, DANE is a weak root of trust with minimal benefits over the existing WebPKI.<br><br>I agree with his analysis. However, DANE has other uses cases that provides for a myriad of opsec and verificational benefits.  As a root of trust, DANE could improve. As a validator, DANE mogs.<br><br>In bmail's setup, the TLSA record at _25._<a href="http://tcp.smtp.bmail.ag">tcp.smtp.bmail.ag</a> is the SPKI hash of a key generated inside the smtp-inbound enclave on first boot, which is sealed under MRENCLAVE. The enclave posts the hash + a fresh quote to a gated API which validates the full Intel chain and confirms the MRENCLAVE matches a published smtp-inbound build before writing the record.<br><br>Gmail, Outlook, and any other DANE-aware MTA refuses to deliver mail to bmail unless the served cert matches that hash. The only server in the world that can present the matching SPKI is the exact MRENCLAVE we published since it is the only one who has the key.<br><br>DANE earns a reason to exist here as a third-party-validation channel that says "the box answering on port 25 really is the binary" that the protocol actually speaks. We used this to chain SGX verification to SMTP!<br><br>To be clear, the TLD can still lie, but good SMTP servers won't deliver.<br><br>The Great DANE is a good boy. :)<br><br><br>4. On PQ Safety<br><br>We use ML-KEM-768 + X25519 hybrid for every key-wrap on the system. Both have to fail for confidentiality to fall since we concat the two shared secrets and HKDF, with the public transcript (eph pub + KEM ciphertext) as the salt.<br><br>I didn't go with the recent adopted IETF sole ML-KEM recommendations, because there's still some unsettled territory here, and further, alleged interference and observably questionable practices in play when determining "rough consensus [1]"<br><br>Hybrid construction costs nothing. ML-KEM provides the post-quantum safety, X25519 does what it provably does today, and an attacker has to break both.<br><br>For those that understand that vunerabilities exist, always, and further understand defense in depth as a necessity is absolute, I would highly encourage participation on the IETF mailing lists go forward to help push forward more pragmatic standards go forward.<br><br>Dr. Bernstein's (aka djb) blog has some great information - <a href="https://blog.cr.yp.to/">https://blog.cr.yp.to/</a><br><br>I have to say I salute him, while admiring in awe, as he continues to defend "we the people," amazingly even solo at times.<br><br>Looking forward to the comments, criticisms, complaints, what if's, why not's, please don'ts, etc.! :-)<br><br>Sincerely,<br>Andrew<br><br>P.S.: In regard to what's encrypted at rest re bmail, all headers, subject, body, etc. are encrypted in TEE or client-side when in-house. The client-side WASM is reproducible and verifiable.<br><br><br>[1] The IETF seems to state that rough consensus is an ever-changing state with the ability to achieve both a positive and negative state whilst maintaining the same properties. You can learn more about it and humming [2] here: <a href="https://datatracker.ietf.org/doc/html/rfc7282">https://datatracker.ietf.org/doc/html/rfc7282</a><br><br>[2] A particularly long thread has been ongoing for over a month debating how to port humming to an online contemporary so it appears this is still within protocol, or at minimum, something taken seriously [3].<br><br>[3] It would be fun to see the various agencies who are allegedly infiltrating hire opera singers for these humming based consensus identifying rituals.</div>