Re: [lamps] Paul Wouters' Discuss on draft-ietf-lamps-e2e-mail-guidance-15: (with DISCUSS and COMMENT)

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

Hi Paul--

Thanks for the discussion and feedback.

On Sun 2024-03-17 18:16:01 +1000, Paul Wouters wrote:
> [ dkg wrote: ]
>> The fact that the messages are authenticatable is critical for many of
>> the systems that use e2ee mail, including things like verification of
>> protected headers.
>
> I am not sure I'd agree with "critical". 

OK, maybe "critical" is too strong, but having cryptographically
authenticated and integrity-checked headers allows the receiving MUA to
reason about the message with more confidence, including things like
what to do when composing a reply to an encrypted message, to avoid even
an encrypted reply from going where it wasn't originally intended to go.

This is especially important for things like control systems governed by
end-to-end cryptographic mail (e.g. the debian archive; mailing lists
like schleuder; DNS registrar controls; etc)

Even without these mechanical advantages, helping the recipient
understand the difference between a deliberately unsigned encrypted
message and a signed encrypted message is … awkward at best.

> I see it more as a user option, a choice of the sender to hand out
> such cryptographic proof or not.

One of the goals of the e2e-mail-guidance draft is usability.  Asking
the user to make a subtle choice each time they send an e-mail increases
the mental load associated with using cryptographically protected mail.
If making that choice has no particular consequence, then it's just a
cost with no benefit.

Streamlining the decisions required of the user is important for
usability.

> There is an unmistakable difference if we sit at a bar and I tell you
> "Roman is impossible to work with", versus a crypto graphically signed
> message of the same.

I agree there is a difference between those two scenarios.

But what this draft asks implementers to consider is whether there is
actually a significant difference between badmouthing Roman in an
*unsigned* e-mail versus badmouthing him a *cryptographically signed*
e-mail.

Either way, the recipient can replay the e-mail to Roman or Roman's
supervisor (sorry Roman!).  Do you think Roman (or his supervisor) will
attach any significant weight to the fact of the end-to-end
cryptographic signature?

Remember that "non-repudiability" only goes so far: i might not be able
to claim that the message was sent from somewhere else, but i can always
claim that my MUA got hacked.  And, remember that "repudiability" itself
also only goes so far: the message that is not cryptographically signed
can be traced/authenticated by Received headers, by MTA logs, by
inspection of a sent mail folder, etc, depending on what access someone
has, and how much certainy the judge requires from the evidence.

Roman will probably feel just as bad when he sees the unsigned mail as
he will feel if the mail is signed.  (and if we're talking about our
ex-AD, he is an unusual case because he actually knows the difference
between signed and unsigned mail -- most other people who are
"impossible to work with" won't even know the difference)

> In other words, mandating digital signatures can surely stifle free
> speech via email.

I'm not as sure as you are about that.  I think the risk of confusing
and difficult choices limiting the reach of e2e-protected mail represent
a much more widespread chilling effect.  People need to know that their
messages will be private except for the people they intend to receive
them.  Each hurdle we put in the way of that has a larger impact than
any subtle nuance between signed and unsigned encrypted messages.

> The choice of medium can be based on the informal vs formal nature of it.
> A slack message can be a lot more informal than an email. Or a text
> message can be seen as informal too. Or a DM on various platforms.
>
> My concern is that you are raising the informality of email to a new
> formality that is not what some people come to expect of it.

I think people already think of unsigned e-mail as formal, as you say
above.  I don't think they'll see this change as significantly
different.

> "Warning: this message was encrypted but not digitally signed. It could be
> a forgery".

will any MUA put the same warning on unsigned, non-encrypted messages
today?  If not, then we're putting warnings on encrypted messages that
will make people reluctant to encrypt. ("i don't want them to get a
warning message when they read this mail")

> I'm not sure if the IETF should step too deep into the UI parts. I'm mostly
> pushing back at you trying to make sending encrypted unsigned messages
> a MUST NOT. If you could quantify that, I would be much happier.

I agree that the IETF should not step too deeply into UX design.  But we
need to think clearly about how to expose simple and straightforward
semantics from the protocols we develop so that the UX designers have a
chance to make something that is actually usable.

To date, that has never been done with e2ee mail ☹

>> The document currently treats the e-mail address as the sender identity,
>> and doesn't grapple with the human-readable name at all.
>
> But how useful is the advise of this draft if all these out of scope things
> are
> not part of the discussion?
>
>> I've opened https://gitlab.com/dkg/e2e-mail-guidance/-/issues/14
>
> I see you addressed it in
> https://gitlab.com/dkg/e2e-mail-guidance/-/commit/fc7fe640873e2725e2d43c5381975acc59cd45f7
> Thanks!

I hope you'll agree that this draft is a step forward toward a usable
e2ee e-mail system, even though there are some things it doesn't cover.

Frankly, the "Future Work" appendix alone describes more outstanding
work than many WGs describe in their charter :/  

>> >         For comprehensibility, a conformant MUA SHOULD NOT create
>> >         multiple copies of a given message that differ in the types
>> >         of end-to-end cryptographic protections afforded
>> >
>> > Can it be clarified whether this is meant "to the same email user" ?
>> > A message send to multiple people, of whom only a subset support
>> > encryption, should still send "multiple copies of a given message
>> > that differ in the types of end-to-end cryptographic protections
>>
>> The text does not mean "to the same user" -- it deliberately means (and
>> i think says clearly) "per message" in order to provide a coherent view
>> to all participants of what kinds of cryptographic properties to
>> associate with a given message.
>
> I don't understand "per message" for example in the context of BCC:s,
> where the message to different people have different headers.

Most Bcc systems that i see today (outside of e2ee mail) send exactly
the same message to each recipient. named recipients and bcc'ed
recipients receive the same underlying message.

Even for Bcc implementations that put a literal `Bcc` header field in
the copy of the message sent to the Bcc'ed recipients, they don't alter
the message in any other way.  And only one copy of the message lands in
the sender's "sent mail" folder.  Doing something as radical as sending
a copy of the message in the clear to some recipients and an encrypted
copy of the same message to other recipients would be a major departure
from the expectation that the message is roughly the same anywhere it
shows up.

>> Your milter is not the only software i've seen that takes this tempting
>> shortcut!  ☺ Do you think that any of these implementations can
>> effectively avoid the pitfalls described in that section?
>
> No, it is a terrible solution :)

:)  i wish it was easier to get that right!  it's certainly appealing
from an engineering perspective.

> I've updated my ballot to No Objection.

thanks!

        --dkg