Subject: [dane] Use OPENPGPKEY or SMIMEA if both are available?

From: Patrick Ben Koetter <[email-masked]>
Date: Mon, 9 Mar 2015 20:59:45 +0100

Greetings,

while thinking about OPENPGPKEY and SMIMEA I came across this question:

What if a recipient publishes both, an OPENPGPKEY and a SMIMEA RR in DNS and
what if a sender (MUA/MTA Filter) is capable to encrypt messages for both
standars S/MIME and PGP.

Which should the sender prefer? Could the receiver indicate a preference?

Has there been any discussion on this? Should there be? Did it take place and
I missed it?

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2015 16:06:28 -0400 (EDT)

> Has there been any discussion on this? Should there be? Did it take place and

It has not been discussed.

I would think this is a local policy decision. Likely, if respondering
to an encrypted message using X, one would encrypt back using X if the
local policy allows this. If sending a message from scratch, I would
think local policy applies?

An email client could prompt the user. An MTA would have to make a
decision on its own, based on its policy.

I wouldn't go so far as to allow the recipient to show a preference. The
recipient shows its accepted methods by publishing the related record in
DNS. This works similar to crypto suite/algo negotiations. The initiator
can pick its favourite from the intersection of what both parties
support.

Paul

---

From: Patrick Ben Koetter <[email-masked]>
Date: Mon, 9 Mar 2015 22:21:15 +0100

> can pick its favourite from the intersection of what both parties

I think there are several options to handle OPENPGPKEY and SMIMEA conflicts.
My intention is to find the one that requires the least or no sender
interaction.

Why? End to end encryption is known to be complicated. That's one of the main
reasons why average users refuse to use it. They consider themselves unable
to make the right decisions. They avoid these conflicts refusing to use
end-to-end encryption at all.

Both, OPENPGPKEY and SMIMEA, carry the potential to increase wider usage of
encryption. They offer a safe way for automated key distribution. All a sender
will have to do is 'send' the message. Given appropriate software, MUA or MTA,
will handle safe key retrieval and encrypt the message for any OPENPGPKEY and
SMIMEA enabled recipient.

Letting the sender decide in case of conflicts - OPENPGPKEY and SMIMEA are
present at the time of sending - puts the burden back on the sender. I'd like
to avoid that because I expect this to be counterproductive for wider
adoption.

One way to handle this without user interaction is to handle it at MTA level.
The operator could specify a preference.

Another way would be to let the recipient specify a preference. Preferring one
over the other would only take place if the sending MUA/MTA was able to deal
with either standard.

The sender would not have to interact with the software to make a decision.
The recipient could indicate preference for standard A e.g. simply because
messages encrypted by A can be read on more devices (desktop/tablet/mobile).
Standard B would only serve as fallback.

This would still leave the option to override on the sender's side. But then
it would be intentionally. Most of the time recipient preference would just
"do the right thing".

p@rick

-- 
[*] sys4 AG

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Mar 2015 22:04:02 +0000

> SMIMEA enabled recipient.

Pick whichever is also supported by the sender (for which the sender
also has a key).  If the sender has a key for both, I would have
historically gone with SMIME since more desktop clients support that.

However, things are changing, because smartphones have a new breed
of email clients, and I'm not sure which is more prevalent on iOS
and Android phones.  Also even if SMIME is more widely understood,
it is prone to raise warnings with self-signed or private CA issued
keys.  And we want to avoid such warnings.

So it is not yet clear which is to be preferred, in practice we
should be so lucky as to have to choose.  Most users have no keys
of either type.

-- 
	Viktor.

---

From: Patrick Ben Koetter <[email-masked]>
Date: Mon, 9 Mar 2015 23:16:30 +0100

> historically gone with SMIME since more desktop clients support that.

ACK

> should be so lucky as to have to choose.  Most users have no keys

Are you saying I am worrying about a problem we don't have (yet)?

p@rick

-- 
[*] sys4 AG