Subject: Re: [dane] OPENPGP --- Privacy considerations

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 1 Aug 2015 09:39:44 +0200

Hi,

> From: dane [mailto:[email-masked]] On Behalf Of Florian Kirstein
> Hi,
> 

> And indeed, there are various things to consider. In the result I am
currently
> in strong favour of SHA instead of base, and I know of people who think
> base32 will make the standard much less attractive at least here in
germany
> where privacy is a big topic - and for PGP users in general, as I expect
they use
> PGP for a reason...

+1

> But first my answer to:
> 
> > >I would see the use of base32 (without extra improvement
> > >techniques) as a security risk. This is because, it decreases the
> > >entropy of SHA256 hash function
> > The planned/suggested use of base32 is *instead of* SHA256. Thus,
> > entropy is not a topic - as there is no hashing.
> 
> I think Hosnieh was referring to the SHA256 done in the NSEC3 records,
> and/or the danger of harvesting the emails from the DNS.

This is one of my major concern. But there is other privacy problem that is
during transmission since before, these keys are not queried from a DNS
server and they were something between MTAs and users. So, imagine you're in
a public place and using WiFi and you want to check your email and send an
important email. It is enough that someone sniff all queries to DNS server
and just gather these values. If it is base32 without any hashing, then this
adversary can easily gather information as only convert it back to utf or
other encoding is enough. 
If it is hashed then  do dictionary attack offline and gather all these
email addresses. (doesn't need to be online too).

So this means that if before, the adversary had hard time to gather these
information by checking all websites or mailinglists. Now it is not true and
by only sitting back while sniffing public wifi he can fetch a lot of such
information and do reverse step to return to return it back to the victims'
emails. Of course, if it is hashed, we complicated his life and he need one
more step.

> The current draft in 6.2 notes, that Email addresses "are not secret" and
The
> hashing is not a security feature. I don't fully agree on the first
sentence, but
> the rest is true.

Disagree with your second sentence. If the purpose of hashing before was to
reduce the size of input values or provide collision free values, this is
not the only use case for that anymore. One example, Passwords are hashed
and kept in databases. If it is not for security reason and it is not to
mitigate plain text attack on the database or storages, then it appears that
I am not understanding the reason!?

Another example is that hashing public key in some mechanism to increase the
strengthen of public key that is not only related to the strengthen of
public cryptography algorithm and key size but also involve the strengthen
of SHA function. You can find plenty of mechanisms, even at IETF, that uses
this method. 

> 
> Adding some paragraph about handling UTF8 (normalize, don't touch
> otherwise) and it's good to go.

I had some discussion about this with some of my colleagues. It makes sense
to do that step because each implementation might use different encoding for
email addresses. In other word, the value for Java might be different than
.net. 
So I am not disagree with that step and I think it is a right step to do.
Furthermore, you have to consider in future the internationalized email
addresses if and if the DNS registrar accepts to have internationalized
domain (e.g. a domain name in German) . So, in that case it makes sense
again to do this step.

Best,
Hosnieh

---

From: Florian Kirstein <[email-masked]>
Date: Sat, 1 Aug 2015 15:16:04 +0200

Hi,

> a public place and using WiFi and you want to check your email
Did you read my full email? Thats EXACTLY what I wrote in a later
paragraph. And it's the reason I wrote I vote for sha. And even would
prefer iterations there %) And see the risk of rainbow tables used
to reverse those.

> reduce the size of input values or provide collision free values
Thats all the draft states. That the hashing was not intended
as security feature. And that is true. If it would have been intended
to secure the transmission, it would include iterations and possibly
some anti-rainbow measures. 

I don't agree with this intention obviously, I was just stating that
(only) for the purpose of harvesting addresses from the zone the hash of
the localpart is not the thing to consider and it's also not helping
much. And that was the main thing the authors were talking about there,
stating that it's the job of the DNSSEC operator to secure the zone,
not the OPENPGPKEY standard. Which is OK for me.

I also don't say hashes are not useable for security functions - but
a simple sha hash today also isn't the strongest one. One could even go as
far and suggest scrypt or similar instead of chopped sha.

So my main points are:

- hash is better than base32 because it makes sniffing recipients from the
network much harder
- if we agree that it is a real problem, we should add iterations AND a SALT
somewhere to the zone, or even switch to scrypt. It's also widely available
in libraries today like for python or perl. But I have no idea how the
others here see that and if it's worth delaying the draft even more. It
would not be too complicated though and even doesn't have the DoS problems
iterations have in NSEC3. 

I think the base32 transmition will actually prevent people from using
for example a thunderbird plugin that looks up keys - for privacy reasons.
I expect a normal hash would be OK for most of those though, after all the
metadata is not uber-secret, it's still in all the mail server logs
on the way and so on. Real paranoid people will wait another 20 years
for encrypted DNS to be widely deployed %) But sending all your recipients
in clear text really is not what you want today...

> addresses
That's where the proposal of normalizing the unicode comes from. And as
far as I remember there were no objections to this so far, it's just not
in the draft yet.

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: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Aug 2015 16:37:18 +0000

> prefer iterations there %) And see the risk of rainbow tables used

My original proposal that introduced hashes for the local part
suggested hashing the full email address to help thwart rainbow
tables.  That was not accepted, because it does not support domain
equivalence via DNAME aliases.  And we've failed to reach consensus
on even a single layer of hashing just the local part.  There is,
however reluctant, some consensus around base32.

No matter what storage encoding of the localpart is used, a passive
wiretap will reveal the domain of each correspondent's key lookup,
and whether that correspondent is new or one that was looked up
previously.  This is inherent in using a cleartext DNS query
protocol.

How important is support for such equivalent domains, relative to
potential privacy gains?  There is no privacy for lookups of DNS
data, until the transmission channel is somehow encrypted, but even
then, unless your local resolver avoids forwarding all queries to
the ISP, the ISP resolver has the plaintext of all DNS queries.

There was some recent discussion of

    https://tools.ietf.org/html/draft-moore-email-addrquery-01

on the IETF UTA list.  As written in that draft the MSA learns the
plaintext of all key lookups, but this is not a data leak, because
in short order the MSA will see the envelope of the final outbound
message.  With STARTTLS on increasingly more SMTP hops, localpart
data is modestly well protected (passive wiretaps may be able to
distinguish between long and short envelope recipient addresses
based on the sizes of TLS packets unless random padding is used to
extend such packets to hide the plaintext length).

Protection from traffic analysis requires Tor (or better).

So trade-offs are inevitable, and evidently make reaching consensus
difficult.

In the UTA discussion, I am running into irrational fear of DNSSEC,
and I think an unreasonable goal of eliminating the MSA as a trusted
party.  Always using the MSA as a proxy would I believe significantly
improve the scalability and abuse resistane of the protocol.
Without the complexity of end-to-end payload signing, the MSA would
need to be trusted.  It may be possible to add end-to-end signing,
but not clear how without DANE publishing the signing keys, and
stapled DANE responses between MUA and MSA.

Given the clear DNSSEC animus of at least some of the parties, I
don't see a way forward that avoids compromising at least one of
the objectives.  Time will tell...

These are not easy to solve problems.  If someone thinks they have
a simple solution that does not compromise on any of the design
goals, they're probably not thinking hard enough.

-- 
	Viktor.

---

From: Florian Kirstein <[email-masked]>
Date: Sat, 1 Aug 2015 20:47:03 +0200

Hi,

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

Probably Hosnieh's and my mails also would have better fit here, but
for the record: we both also see big privacy issued with the base32
encoding, not worth the theoretical benefits.

As I already wrote: I'd rather drop the lowercasing (which caused much
of the discussion leading to base32) then go without some "scrambling"
of the localpart. Even tough I still believe lowercasing before lookup
would not collide with current RFCs (as it's a key lookup, not mail
routing). But if it has to be - let's try without that and see what
real life experience shows us. 

Greetings,
Florian

-- 
[*] sys4 AG

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Aug 2015 14:58:47 +1000

In message <814D0BFB77D95844A01CA29B44CBF8A7015D2DF4@lhreml504-mbs>, Hosnieh Rafiee writes:
> Followup
> However, a few DNS servers support 0x20-Bit Encoding, but this
> approach is not supported by base32 which has its own security risk.

Hogwash.  With base32 is perfectly capable of working with 0x20.
You just have to appropriately map alphas when decoding which
is inherent when you send base32 through the DNS.

>  Unless.. we get back to the technique for DNScurve to be able to differentiate lowercase
> and uppercase characters in 
> 
> 
> < http://courses.isi.jhu.edu/netsec/papers/increased_dns_resistance.pdf>
> 
> Thanks,
> Best,
> Hosnieh
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]