Subject: [dane] OPENPGP and SMIME local part question

From: "Olafur Gudmundsson" <[email-masked]>
Date: Wed, 22 Jul 2015 12:00:54 -0400 (EDT)

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

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 22 Jul 2015 16:20:09 +0000

I am in favor of a decision and this sounds like a not terrible one :)
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

From: Olafur Gudmundsson <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 22, 2015 at 12:00 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [dane] OPENPGP and SMIME local part question

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

---

From: George Michaelson <[email-masked]>
Date: Wed, 22 Jul 2015 18:25:10 +0200

I believe incursion into the lhs@ to define behaviour is very rare. This is
a moment which bears thinking about, and will incur review overhead from
people.

I'm in favour btw. But, (and I doubt anyone doesn't expect it) there will
be questions to be asked about diving into lhs@ because its been very very
uncommon.

-G

On Wed, Jul 22, 2015 at 6:00 PM, Olafur Gudmundsson <[email-masked]> wrote:

>
>
> 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,
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>
>

---

From: James Cloos <[email-masked]>
Date: Wed, 22 Jul 2015 13:07:12 -0400

>>>>> "OG" == Olafur Gudmundsson <[email-masked]> writes:

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

Since I've posted on the topic before, I'll note that I have no
objection to that scheme.

(Is that 60 base32-chars, or 60 chars before encoding with base32?)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Jul 2015 15:16:46 -0400 (EDT)

> (Is that 60 base32-chars, or 60 chars before encoding with base32?)

60 chars after encoding to base32, because the whole point is that a
label cannot be more then 63 characters.

Paul
(note my earlier python script did not cut the wya Olafur posted :)

---

From: James Cloos <[email-masked]>
Date: Wed, 22 Jul 2015 15:25:11 -0400

>>>>> "PW" == Paul Wouters <[email-masked]> writes:

PW> 60 chars after encoding to base32, because the whole point is that a
PW> label cannot be more then 63 characters.

Yes, for some (dumb) reason I had 127 in my head instead of 63.  [SIGH]

-JimC

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 25 Jul 2015 22:44:18 +0000

> On Jul 22, 2015, at 12:00 PM, Olafur Gudmundsson <[email-masked]> wrote:
> 
>  
> Dear Colleagues 
> 

Just to clarify, we’re not talking about Base32Hex (Section 7 of https://tools.ietf.org/html/rfc4648#section-7 ), right?  I only ask because the RFC points out that base32hex is the alphabet used by DNSSEC’s NSEC3 record.  I’m not sure it matters, but the RFC mentions:
	One property with this alphabet, which the base64 and base32
	alphabets lack, is that encoded data maintains its sort order when
	the encoded data is compared bit-wise.
Would that be useful/relevant/etc. here too?  

In either case, I just thought it would be worth clarifying here.

Eric

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Jul 2015 11:21:17 -0400 (EDT)

> Would that be useful/relevant/etc. here too?

Correct, we are talking about base32 and not base32hex encoding.

The sorting does not matter for us as these are one to one lookups and
we are not building any chains.

> In either case, I just thought it would be worth clarifying here.

We will add a reference to section 6 specifically to avoid confusion.

Thanks,

Paul

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 31 Jul 2015 14:26:40 +0000

Hi,

I have reviewed this draft. I have some questions and feedbacks...

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 (As far as I know based on my experiment with SHA256, SHA256 are case sensitive) which result in possible attacks on usernames and forging usernames. 

Unless they use the same techniques that is used for DNScurve key hashing. < https://en.wikipedia.org/wiki/DNSCurve > . But if they use this technique then the size of the message is no longer 32 because in that technique for characters that does not have any base32 value, they use the combination of characters that already exist in base32. As a simple example, for lower 'a' that is not in base32, they use 'AB'. 

In other word, the size of the 28 bytes hash value is no longer 32, but it is around 51. But if the the same technique as DNScurve is used, it is better than base64 because base64 also doesn't support all characters that exists in the result of SHA256. 

Furthermore, I also do not understand the reason why in section 3 they are converting the result to lowercase. This doesn't affect the SHA256 result. Since the username in email is always lowercase, it make sense to do this lowercase process before encoding to UTF-8 because the assumption is that the email address is always lowercase. Therefore, converting UTF-8 result to lowercase just decrease the entropy of SHA256 function. Then allows attacker to easier proceed with dictionary attack because it can just skip many inputs values for SHA256.  This means, with this approach the probability of collision for SHA256 increases.
 
So, in my opinion, before having any decision, the authors need to bring some analysis of base32 and base64 and lowercase, uppercase and SHA256 and share the analysis so that to be clear how much security risk it might provide for email users.
 
<snip>

should already be encoded in UTF-8 (or its subset
      ASCII).  If it is written in another encoding it should be
      converted to UTF-8.  Next, it is turned into lowercase and hashed
      using the SHA2-256 [RFC5754] algorithm,
</snip>

Thanks,
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 31 Jul 2015 14:31:22 +0000

Followup
However, a few DNS servers support 0x20-Bit Encoding, but this approach is not supported by base32 which has its own security risk. 

 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

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Jul 2015 17:31:22 +0200

Hello Hosnieh,

On 31 Jul 2015, at 16:26, Hosnieh Rafiee wrote:

> 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 (As far as I know based on my experiment with 
> SHA256, SHA256 are case sensitive) which result in possible attacks on 
> usernames and forging usernames.

The planned/suggested use of base32 is *instead of* SHA256. Thus, 
entropy is not a topic - as there is no hashing.

(That said, encoding a SHA256 hash as base32 would not lose entropy. 
Treating a base64-encoding of SHA256 as something base32-like would lose 
entropy, but that’s a terrible idea for several reasons and nobody is 
suggesting it).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 31 Jul 2015 17:13:31 +0000

Hello Peter,

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Peter van Dijk

> >> encoding of local part with 60 character labels, shortest label is
> >> the left most label.
> >
> Treating a base64-encoding of SHA256 as something base32-like would
> lose entropy, but that’s a terrible idea for several reasons and nobody
> is suggesting it).
> 

OMG... IMO, in this case the approach will sacrifice users' privacy. Is there any thought of spams that the email owners would receive? 

Well.. I guess the draft wants to store this mapping on a DNS server right? And this DNS server is a public one... this means, we are handing over all emails to the spammers... 

I hope I am not correct :-/
Best,
Hosnieh

---

From: Florian Kirstein <[email-masked]>
Date: Fri, 31 Jul 2015 20:22:09 +0200

Hi,

I have done quite some research on DNSSEC zone security, NSEC
and NSEC3 enumeration, attacking various zones using a GPU
cluster and similar things, so I think I can judge the relevant
attack vectors quite well...

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

We should not forget: the question is not only, if providers will
publish keys for their zones, but also if clients will adopt the
standard and query those keys. Both has to happen for the standard
to be a success.

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

I think Hosnieh was referring to the SHA256 done in the NSEC3
records, and/or the danger of harvesting the emails from the DNS.

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. And also the solution: if you are worried
about zone walking, using and adjusting NSEC3 or similar counter measures
(white lies) is the answer, not a different input encoding. NSEC3 uses
iterations and you can adjust how many (various things have to be
considered there, but that's nothing special of this draft but normal
DNSSEC operation) - so if there is one SHA-step more ore less to be
done on the local part will add very little on the attacker side. So
using base32 will NOT decrease security here in any way relevant in
real life.

Of course, if you use NSEC (like fedoraproject did for their
openpgpkey test deployment) base32 is much worse than chopped sha - but
it you are concerned about your zone data, simply don't use NSEC.

So @Hosnieh: cosider using zone walking counter measures matching your
paranoia level, and the SPAMMER issue should be gone.

But there is a second side to consider: the DNS requests of the people
sending mail. And there we (currently) don't have a (widely deployed)
solution to hash or encrypt those on a DNS level. That means using 
base32 the emails of recipients I am sending mails to will go in
clear text over the wire. And that's not good.

Today many emails including their metadata at least in germany are fully
encrypted from the sender to the recipient (not end to end, but on
every segment) - SMTP submission using TLS and verified cert,
intra-server SMTP with opportunistic TLS (vulnerable to MitM, but
secure against passive attacks), IMAP with TLS and verified cert on the
receiving end. And especially sending and receiving end is where pratical
snooping is often possible, especially also active MitM.

That means you can use your laptop in a cafe, your tablet in a hotel,
and even without a VPN you can be pretty sure people around don't snoop
on your mail communication. With OPENPGPKEY+Base32 deployed, they would
see for EVERY mail you send the recipient in clear text. Even for the
(currently 99.x%) cases, where the recipient doesn't have an openpgpkey
record(!).

Yes, one iteration of hash isn't a very good protection, especially
for simple formed adresses. But still it is MUCH harder to snoop
than clear text. Meaning: the NSA (and I with my GPU cluster) sniffing
your Hotel WiFi will be able to unhash 80+% of your recipients. But
the guy sitting on the table next to you with his cool $0.99
hacker-app for android or some guy fireing up wireshark for fun won't,
unless he has a good rainbow table which unfortuneately (unlike for
NSEC3) is pratical there. Still: attacking a hash is something
completely different from simply sniffing a clear text.

I have spoken to people who are really concerned by this and won't
be enthusiastic about deploying this standard when it sends adresses
in clear text through the net. Personally, from a privacy point of
view, I'd also prefer to even see some form of iterated hashing
implemented (having a record in the zone telling how many iterations
or something like that), but I understand that this would be a completely
new topic making things even slower, what do others think?

So: a strong vote from my side to stay with chopped sha256. I still think
the advantages of base32 are more theoretical and people who really want
to use these advantages will have to implement own responders - if you're
willing to do that you also could implement a webfinger service or
similar. The OPENPGPKEY standard for DNS should be a simple way to
publish the keys of your zone, and the current 03 draft provides that.

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

Greetings,
Florian
P.S.: On a side note: yes, lowercasing also weakens the attack surface
of the hash. But not much, as unlike passwords the positions in which
you uppercase an email are pretty obvious in real life. But actually, 
after many discussions with people actually using PGP regularly, I 
would even prefer to drop the lowercasing (possibly allowing the client to
try it as second guess - will be done anyway) over using base32.

-- 
[*] 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