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

[Stephen Farrell <[e-mail]>]

Hiya,

Sorry for the slow response. Bottom line is I accept that
the WG have consensus to put this out more or less as it
is (recognising it's imperfections) so it's ok that I'm
either wrong or in the rough:-)

More detailed responses below.

On 06/07/2023 18:35, Daniel Kahn Gillmor wrote:
> 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?

Ah fair enough I must've missed that.

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

I agree it can be hard to get feedback, but equally if we
don't know what implementers of the most commonly used MUAs
think of this then we're in an undesirable position in that
we don't know which bits of this might help and which may
be ignored etc. I accept being in the rough on this.

> 
>> - 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?

Better, yes. Still not correct though, but it's ok.

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

Yep, that's better, thanks.

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

Ack.

>> - 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?

So my question was about whether there's evidence here not
whether one or other situation was better. I'm ok that we
proceed without that evidence.

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

ack.

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

I still think the text ought not propose things we know
won't be done, but I'll accept being in the rough.

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

Again, I'll accept being in the rough.

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

That's fine thanks.

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

ack.

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

Ok.

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

Ok.

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

Ack, thanks.

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

ack

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

Ok

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

Ack, thanks.

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

I still don't think the guidance here is great, but I'll
accept being in the rough.

Cheers,
S.

PS: Skipping nits, just to be sure I don't cause another
iteration by accident:-)

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