Re: [lamps] WG Last Call: draft-ietf-lamps-e2e-mail-guidance-08

[Daniel Kahn Gillmor <[e-mail]>]

Hi Stephen--

thanks for this review, and sorry for the delay in responding to it.

I've just published draft -09 which includes a handful of small changes
in response to your observations below.  In this message i've tried to
respond to each of your points.

Please let me know if i've missed something or if you have other fixes
which you'd prefer to see made.

On Wed 2023-06-21 17:04:28 +0100, Stephen Farrell wrote:

> - general: other than mentions of p#12, I don't see any
> guidance about using multiple MUAs with the same (set of)
> private key(s). Multiple MUAs is I think now the most
> common setup and ignoring that seems wrong. I know we
> don't have really good answers, but ignoring that doesn't
> seem like a good plan to me. I do see A.3.1 but think
> the main body should at least recommend something
> explicitly for this such as saying that MUAs should
> support import and export of credentials for this
> reason.

I agree with you that this particular situation (shared keys across
MUAs) is important and currently underspecified.

As you observe, A.3.1 ("Cross-MUA sharing of Local Certificates and
Secret Keys") calls this out for future work.

section 8.2.1.1 ("User Certificates for S/MIME") already says:

    An S/MIME-capable MUA that has access to user certificates and their
    corresponding secret key material should also offer the ability to
    export those objects into a well-formed PKCS #12 object that could
    be imported into another MUA operated by the same user.

What other text do you want to see added?

> - general: have MUA developers commented on this? I
> think we'd be very wise to ensure that's happened before
> we publish.

The three main editors (Bernie, Alexey, and myself) all contribute to
different MUAs (Bernie works with pEp, which produces several MUAs and
MUA plugins, see https://pep.foundation/pEp-software/; Alexey works on
Isode's Harrier (https://www.isode.com/products/harrier.html); and i
contribute (with particular substantial focus on cryptography) to
notmuch (https://notmuchmail.org) and in smaller ways to several other
free software MUAs).  We've been asking the LAMSP group for comment
here, and doing private outreach to other MUA developers.  If no one
else responds publicly, i'm not sure what else we can do.

> - section 2: "it is likely is that the user will continue to encounter
> unprotected messages, and may need to send unprotected messages" I
> think that's utterly wrong, and importantly so - it is certain that
> both will happen, and both will happen far far more frequently that
> dealing with e2e encrypted email, even if we'd prefer the opposite
> were true.

You're right, of course, about the scenarios that users of a MUA will
see.  But I think the text is actually saying the same thing you're
saying, just in a more mild "dry engineering humor" form ("likely"
instead of "certain").  I've changed it from "it is likely" to "it is a
near certainty."  Is that better?

There are in fact contexts where an e-mail acount is used entirely
privately; but they are few and far between, and a dedicated
communications channel may well be better implemented on a bespoke
channel, rather than on top of a MUA.

> I think that has consequences e.g. 2.3 says "But a user whose e-mail
> communications are entirely end-to-end protected might instead want to
> know which messages do not have the expected protections" but that's
> totally unrealistic and hence not good guidance for an MUA developer.

I've changed this sentence to start with "But a user whose private
e-mail communications *with a given correspondent, or within a given
domain* are entirely end-to-end protected…" to make it clear that no one
currently believes it's plausible to have an entirely end-to-end
protected e-mail inbox today, though (as it says in the subsequent
paragraph) there are some contexts where it's possible and reasonable to
hold such an expectation about a given e-mail message.

I've also added a subsection to the "future work" appendix that talks
about expectation management and its interaction with security
indicators.

> - section 3.1: 'If the user is unaware of the protections,
>    then they do not extend all the way to the "end".' I
> think I don't agree with that but not 100% sure. Couldn't
> it also be a tactic to try e2e encrypt as much as possible
> (even with low quality key management) and only tell the
> user abou it later?  Is there evidence that the quoted text
> above is the better approach?

I think what you're describing here is opportunistic encryption.  I'm a
fan of opportunistic encryption, where the user doesn't even know that
it's happening when it happens, or unless they do a manual inspection.
But i don't think it's end-to-end.  If the parties at the end won't
notice if the encryption goes away, then how can we say that the
encryption is even present?

> - Similarly, 3.1 proposes unprotected/verified/confidential
>    as a model.  Where is there evidence that that's a good
> model? I don't have a problem with separating out
> encrypted-but-not-signed but I doubt "verified" vs
> "confidential" would be meaningful to users.
>
> - 3.2 seems to assume that opportunistic methods can only
>    apply to mail transport security. I think that's
> incorrect.

how so?  the first sentence acknowledges approaches like
"opportunistically encrypting on a per-recipient basis".  That's
something that can only be done at the message level, not at the
transport level.

I've tried to clarify the text in that section to acknowledge that
opportunistic transport protections can exist *as well* as opportunistic
message protections.

> - section 8: while expecting an MUA to check for revocation
> is what we've always wanted, afaik, it mostly doesn't
> happen, except maybe in enterprise s/mime deployments
> (even there, I'm not sure what's the reality). I don't
> think the guidance here ought pose impossible problems
> to MUA developers, so text along the lines of "if you
> do check revocation, here's <guidance>, but we know
> mostly you don't."

I agree that checking revocation is a fuzzy/dubious process for most
MUAs today, and i haven't heard anyone offer compelling guidance on how
to do it.  There is a section tracking this gap in the Future Work
appendix, see §A.2.3.

> - 8.1.1: I don't know that the eku ckeck (the last bullet)
>    is reasonable to require - can you re-assure me on that?
> (Concern is that might cause a pile of existing certs to no
> longer be usable, for not super-great additional benefit.)

The security goal here is related to various forms of key reuse concerns
-- the same ones that Eliot and I were talking about (e.g. DROWN and
IKE) for why we want certs to only be signing or encryption.  If a user
is using a non-e-mail key for e-mail encryption, then any attack on the
other protocol could break the confidentiality of their e-mail messages.

Consuming implementations *should* be conservative here, to encourage
certificate generators to do the right thing.  We've already covered
this in RFC 9216 (sample certificates for e-mail) that are intended to
show reasonable practices.

Furthermore, i'm under no illusion that the recommendations in this
draft will be adopted universally next week or next month even -- this
is a slow-moving ecosystem.  But most X.509 certificates expire within a
year or two at most.  Having this guidance be clear for certificate
issuers today, to understand consequences of their actions is important
so that future certificates are more likely to be issued with the
appropriate eKU.

If someone has evidence that shows that there are many certificates
currently in use that this will break, and which do not expire within a
few years, or that there are widely used CAs that issue 
certificates for use with e-mail with an eKU but without the e-mail OID
or the anyExtendedKeyUsage OID, then i'd be happy to dig more deeply
into the details of the specific situation.

> - 8.2.1.1: wrt p#12, there's a new I-D to be discussed
> at ietf-117 secdispatch I think that could be well worth
> considering - some text there might remove the need for
> some here for example

I think you're talking about draft-woodhouse-cert-best-practice -- is
that right?  I've added an informational reference to this section to
refer to it.  I'd prefer to not remove anything from
draft-ietf-e2e-mail-guidance at the moment, since (a) i don't want to
make it a normative reference, and (b) we don't know how that document
is ultimately going to turn out.

> - 8.2.1.1: do any CAs have operational support for rfc8823?  If so,
> are any free? (I'm not aware of such.) If there were such, then I'd
> argue for making a stronger statement asking for MUA support. If not,
> current text is probably ok.

I'm not aware of any at the moment.  Let's Encrypt is currently not
provisioned for that
(https://community.letsencrypt.org/t/s-mime-acme-using-rfc8823/150227),
and i wasn't able to find anyone offering it today.
https://acme.castle.cloud appears to offer tooling capable of
implementing the server side (and the client?) but i don't know of any
widely-trusted authorities that have it deployed.

> - 8.2.1.2: does any MUA do anything like the "pruning"
>    recommended in the last para? If not, seems like a bit of
> a stretch to ask. (And, is that a real problem anyway? Not
> sure myself.)

Yes, bloated OpenPGP certificates are a real problem (see
draft-dkg-openpgp-abuse-resistant-keystore for way more detail than you
probably want).  There are multiple OpenPGP implementations that do
pruning of various qualities (e.g. GnuPG has an "export-minimal" option,
and sequoia has "sq keyring filter"), and there are MUAs (including, for
example, those following the Autocrypt guidance) that deliberately prune
certificates for minimization before transport.

> - 8.2.1.3: Why a *3rd* party? ISTM an external key
>    generator would be a 2nd party. Also, how could this work
> for a web MUA? Do you consider the web server a 1st party?
> If so, that's maybe reasonable given the code is coming
> from there, but worth saying.

good call, i've changed it from "untrusted third party" to "untrusted
external party".

I think if you're using a web MUA, your web server is part of your
trusted computing base, so it's not an untrusted external party.  I'm
not wild about that scenario from an e2e perspective (the server can
often be run by a potential adversary, and most people are not able to
identify that risk, let alone vet it properly), but i don't think we
need to call out web-based MUAs in this particular subsection any more
than any other.

> - 8.2.2: wouldn't it be counterproductive for an MUA to
>    warn about each specific thing there? If so, I'm not sure
> what kind of warning is envisaged. 

This section specifically says that proactive fixing is better than
warning, but that we don't have detailed guidance on how to do the
fixing (that's part of the "Active Local Certificate Maintenance"
subsection of "Future Work").  I agree that warning about each specific
thing would be pretty noisy, but the original intent was just to
encourage the MUA to do a certificate health check, and to warn the user
if their certificates might be unacceptable to a reasonable peer.

I've added a sentence with more recommendations about the warning,
encouraging an aggregate warning with simple language and
recommendations for next steps.

> The 3rd bullet also seems a bit wrong given that most MUAs support
> multiple accounts.

That's a good point, thanks; i've reframed the section to be in
reference to a single e-mail account managed by the MUA.

> - 8.2: Is this section generally missing guidance for
> MUA developers on where to look for certificates in inbound
> messages? I don't know if that ought be identical to the
> guidance on where to put 'em in outbound messages but
> there could be different guidance needed, not sure.

§8.2 is about the user's own certificates, not certificates for the
user's peers.  So no, guidance about looking for certificates in inbound
messages wouldn't be appropriate to this section.

The "Future Work" appendix has "Certificate Discovery from Incoming
Messages", describing some of the challenges about importing
certificates from arbitrary incoming messages, without offering a
specific prescription for how to do it.  As the document says, I think
we currently lack consenus or understanding around "how to assemble and
manage th[e] cache" of discovered certificates.

> - 9.1: I expected guidance on how to avoid problems when
> a message in the sent folder is encrypted for the sender
> but the relevant certificate has expired - that used
> to be a common bug.

Hm, good call!  But it's not just about sent messages, that particular
bug can strike the regular inbox too.  I've added a separate subsection
to "Common Pitfalls and Guidelines" about "Reading Encrypted Messages after
Certificate Expiration".

> - 9.8: is it really feasible to pre-fetch an HTML resource
> and include it inline? I'd be surprised if so. Same for
> using SRI as the content may be intended to change and
> the MUA can't know that.

Yes, it is indeed feasible to pre-fetch, or to use SRI. A MUA that
renders an HTML message during composition (i.e. in a WYSIWYG interface)
will pre-fetch the resource so that the composer can see how the message
is expected to look on receipt.

If the resource is intended to change, then a signature over the message
is of dubious value, because the thing being signed is not at all clear
to the user.  If the resource is *not* expected to change, then
pre-fetching or using SRI is reasonable.

The point in this subsection is about an interaction between MUAs: a
reasonable recipient MUA shouldn't indicate that a message with mutable
external content is signed (or fully end-to-end encrypted, since the
external resource is visible to the HTTP origin).  So if the *sending*
MUA intends to sign and/or encrypt, it should account for the reasonable
receipient behavior by ensuring that the entire message is covered by
the expected cryptographic protections.

> nits:
>
> - intro: be good to explainA sentence of two, in
>    case the URL goes away (and/or find a better reference)

done (for EFAIL), thanks.

> - 2.1: I agree with "cryptographic protections should adply
>    to the message as a whole" but what about when a message
> is forwarded? Could be better not mentioned I guess.

I agree with you that there's an edge case here, but including it in the
beginning of this subsection makes it much harder to understand the main
point.  I've added a parenthetical aside to the end of this subsection.
I would be fine removing it if folks think that it's too distracting.

> - 2.3: I don't understand "Note also that some messages are
>    expected to be confidential, but other messages are
> expected to be public -- the types of protection (see
> Section 3) that apply to each particular message will be
> different. And the types of protection that are expected to
> be present in any context might differ (for example, by
> sender, by thread, or by date)."

What this means is: If you and i exchange e-mail regularly, and i always
sign my mail to you, you might have an expectation that i sign my mail.

Or, if I send you encrypted mail, and you respond, i should expect your
response to also be encrypted, or else something has gone wrong.

(or, if i am used to getting signed mail from you, but i also know that
your signing certificate expires on thursday, i would also *not* expect
to see signed mail from you after thursday unless i find a new key)

do these examples make the subsection make more sense? should i add them
in?


> - 3.2: maybe a ref to RFC7435 could be useful?
> seems

Done, thanks.

> - 6.4: "the certificate that made the signature" is an odd
>    phrase, and seems basically incorrect, "the certificate
> intended to be used to verify the signature" is better
> perhaps

Good catch.  I've changed it to "the certificate used to verify the
signature".

> - 8.1.1: the MUA is selecting certs for peers that it
> thinks are capable of decryption, not encryption

hm, the MUA wants a peer that is capable of decryption, but it wants a
cert that is encryption-capable.  i see how the language was ambiguous
there.  I've improved it.

        --dkg