Subject: Re: [dane] OPENPGP and SMIME local part question

From: Patrik Löhr <[email-masked]>
Date: Sat, 01 Aug 2015 20:05:30 +0200

Hello everyone,

At Posteo, we've implemented OPENPGPKEY and SMIMEA. We are a provider of
email accounts (exclusively on a paid basis) with a strong focus on
privacy and security.

We think it would be better for the local parts to use hashing.

Our two points:
 - The discussion obviously came up because of trying to determine a way
to find entries when users use upper and lower case characters. From our
perspective, this is not a problem that these drafts can solve.
 - Base encoding equates to plaintext transfer and for a security
feature, privacy should not be disregarded.

In detail:
For us it is not a question for these drafts, whether local parts should
be normalised or not. The drafts complement email, and they should
therefore not introduce their own interpretation of email. This runs
contrary to the sense of the RFC system and would in that form
presumably delay or prevent adoption of the drafts. For us it is
perfectly clear that the local parts are either written the same and
match, or not. If the email community thinks that there is a problem
with the local parts, then that is, in my opinion, a matter for another
draft. OPENPGPKEY and SMIMEA should not be used for work on a different
project.

Hashing of local parts is definitely a great advance over plaintext
transfer in terms of security. Even if hashing was not initially
intended as a security feature, it is one. In any case, it distinctly
hinders the possibility of simply reading the data in DNS requests -
data that could convey a lot about the communication behaviour of users.
Hashing is from our perspective a necessary first step, especially when
DNS requests do not occur encrypted. Of course, hashing does not protect
against "decryption" - but it makes a distinct difference whether I need
to make a targeted attack on a hash, or can arbitrarily search through
the plaintext in a stream of data.

We would strongly welcome it if the drafts were to move forward with
hashing, in terms of acceptance as a genuine security feature at the
service of internet users. We need as much security as possible; the
Snowden revelations demonstrated this.

Best regards,

Patrik

Am 22.07.2015 um 12:00 schrieb "Olafur Gudmundsson" <ogud at ogud.com>:

Dear Colleagues

The sense of the room in the IETF-93 meeting was to do do a BASE32
encoding of local part with 60 character labels,
shortest label is the left most label.

If you can NOT live with this path forward now is your last chance to
say so.

By August 1'st the chairs will instruct editors how to proceed.

Warren & Olafur

-- 
Patrik Löhr

Posteo e.K.
Methfesselstr. 38
10965 Berlin

web <https://posteo.de>

Handelsregister: Berlin-Charlottenburg · HRA 47592 B

---

From: Paul Wouters <[email-masked]>
Date: Sun, 2 Aug 2015 10:43:46 -0400 (EDT)

> perspective, this is not a problem that these drafts can solve.

But the choice to solve this point is "allow two lookups" or "lowercase".

> data that could convey a lot about the communication behaviour of users.

But you would only be obfuscating the query, not the answer. The answer
is actually even more interesting because it contains the entire key,
possibly more email addresses as ID's and signatures. Assuming the key
id the user asked for is present on the key obtained, it's trivial to
hash the keyids and find the original query data.

So you would gain security by hashing only for those you are willing
to send plaintext email to?

DNS privacy would help but then you should also be unwilling to use any
random wifi network's DNS server, and build a VPN to a trusted DNS
server farm.

I would say let DPRIVE solve the DNS privacy for all DNS RRtypes.

Paul

---

From: Florian Kirstein <[email-masked]>
Date: Sun, 2 Aug 2015 17:01:49 +0200

Hi,

> But the choice to solve this point is "allow two lookups" or "lowercase".
If people see big issues with lowercase, I could live with "allow two
lookups" (one lowercase) to handle people entering addresses manually.
An UI could optionally (independant of the lookup) warn if the keys
User-ID differs from what he entered. A milter of course can't do that.

But as a milter's only other option is to send unencrypted, I would not
see a problem there even in the theoretical case of a case collission.

So I really don't see the benefits of base32 worth the privacy breach.

> is actually even more interesting because it contains the entire key,
Not really "more interesting" - someone who knows the email address
can query the key himself...

But of course, for successfull queries the answer would be visible. But
for those at least the mail will most likeley be encrypted then :)

The problem I (and I expect also Patrik) sees is all the "useless"
queries. If a mail server operator wants to implement a milter, or a
user wants to install a MUA plugin looking for keys, this will look
up every address passing through. And we all know: for now that will
in most cases NOT give a result for a forseeable future. So he will
consider: is the few cases I get a key back worth the privacy leak for
ALL THE OTHER addresses?

And I see a big risk that this will slow or completely hinder deployment
of such client side implementations, which will lead to not many people
offering the recrods, which in the end will lead to suffering... I mean
failure of OPENPGPKEY.

And of course I totally agree that the real answer is DNS privacy, but if
we wait for that to be widely deployed we can really delay our draft for
another few years... So in my opinion it should be designed in a way
that it at least offers the easy possible privacy by hashing, making it
impossible to simply snoop all the addresses. I think it makes a big
difference for the people on the client side.

Greetings,
Florian

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstrasse 15, 81669 Muenchen

Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 2 Aug 2015 12:30:40 -0700

On Sunday, August 2, 2015 7:44 AM, Paul Wouters wrote:
> ...

Uh, No. DPRIVE is chartered to solve a different problem: prevent observers
from gleaning meta-data by looking at the DNS requests originating from a
client.

I am concerned that we cannot keep email addresses and PGP keys private if
we publish them in the DNS. Data published in the DNS is there to be read by
everybody, there is no access control whatsoever. If we are concerned with
the privacy of email addresses, then we should not publish them in the DNS.
In that case, we would need a specialized service, probably incorporating
some form of control based on a "social graph." 

-- Christian Huitema