Hi LAMPS and OpenPGP folks--
In the hopes of providing a useful space for discussion of effective
implementation of end-to-end crypto for e-mail clients, i've just
published the draft identified below.
https://datatracker.ietf.org/doc/draft-dkg-lamps-e2e-mail-guidance/
https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.html
Abstract:
End-to-end cryptographic protections for e-mail messages can provide
useful security. However, the standards for providing cryptographic
protection are extremely flexible. That flexibility can trap users
and cause surprising failures. This document offers guidance for
mail user agent implementers that need to compose or interpret e-mail
messages with end-to-end cryptographic protection. It provides a
useful set of vocabulary as well as suggestions to avoid common
failures.
This is implementation guidance -- it covers some protocol structures
but doesn't introduce any novel protocol elements. Rather, it gives
pointers that explain common problems, subtleties and nuances that a MUA
implementer might not understand about encrypted mail. You might think
of it as a response to some of the problems that came up a few years ago
in "EFAIL" (https://efail.de).
The draft formalizes a few useful notions. In particular it documents
"Cryptographic Envelope" and "Cryptographic Payload" as concepts that
hopefully winnow down the space of infinite MIME recursion into usable,
sensible structures for e-mail. I've pulled these definitions out of
draft-autocrypt-lamps-protected-headers because they apply whether
headers are protected or not. (I'll get to the protected headers in a
separate conversation)
I'm hoping to discuss this draft on the LAMPS mailing list
(spasm(_at_)ietf(_dot_)org) because of the coverage there of S/MIME and
cryptographic e-mail more generally. But the principles are identical
for PGP/MIME, so the draft covers PGP/MIME as well. Both standards exist
and are in use, so cryptographic MUAs need to realistically grapple with
that situation. I hope that developers who care about only one camp can
see the moral equivalence of the two schemes and try to share tips that
apply generally to cryptographic MUAs.
If you're an implementer of a cryptographic MUA (or want to be), i hope
you'll read the draft, offer commentary and share your insights. I
welcome interested co-authors as well.
The draft is written in pretty simple markdown, and for minor edits i
welcome merge requests and bug reports at:
https://gitlab.com/dkg/e2e-mail-guidance
Any MRs or bug reports on gitlab for more substantive changes are
welcome as well, but i encourage bigger conversations to target the
LAMPS mailing list, and i'll use the issue/MR tracker on gitlab to track
the mailing list discussion.
If there's room in the upcoming LAMPS meeting at IETF 109 to discuss
this, i'd be happy to lead a discussion for 5-10 minutes, but discussion
on the mailing list is more important.
Regards,
--dkg
On Sat 2020-10-31 11:14:04 -0700, internet-drafts(_at_)ietf(_dot_)org wrote:
A new version of I-D, draft-dkg-lamps-e2e-mail-guidance-00.txt
has been successfully submitted by Daniel Kahn Gillmor and posted to the
IETF repository.
Name: draft-dkg-lamps-e2e-mail-guidance
Revision: 00
Title: Guidance on End-to-End E-mail Security
Document date: 2020-10-31
Group: Individual Submission
Pages: 19
URL:
https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dkg-lamps-e2e-mail-guidance/
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp