[Cryptography] In code we trust, hybrid PQ and the rehabilitation of DANE

[Andrew Lee]

Greetings to the distinguished Veterans, my Upperclassmen, and Grand Elders,

We built an end to end verifiable chain for e-mail, and I want to share
four things to this list specifically.

You can verify it: https://bmail.ag/verify

1. Operator Trust

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.

- Hushmail decrypted and handed over confidential data.
- Lavabit had to seppuku since a single key would have resulted in handing
over confidential data. I salute you, Mr. Levison.
- Tutanota complied with a german court order to quietly perform a backdoor
op.
- Proton logged a climate activist's IP

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."

Operator trust is the single weakest link.


2. Attestation + Reproducible builds

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.


3. DANE

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.

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.

In bmail's setup, the TLSA record at _25._tcp.smtp.bmail.ag 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.

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.

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!

To be clear, the TLD can still lie, but good SMTP servers won't deliver.

The Great DANE is a good boy. :)


4. On PQ Safety

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.

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]"

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.

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.

Dr. Bernstein's (aka djb) blog has some great information -
https://blog.cr.yp.to/

I have to say I salute him, while admiring in awe, as he continues to
defend "we the people," amazingly even solo at times.

Looking forward to the comments, criticisms, complaints, what if's, why
not's, please don'ts, etc.! :-)

Sincerely,
Andrew

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.


[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: https://datatracker.ietf.org/doc/html/rfc7282

[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].

[3] It would be fun to see the various agencies who are allegedly
infiltrating hire opera singers for these humming based consensus
identifying rituals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260502/687a89c1/attachment.htm>