Subject: [dane] AD review of draft-ietf-dane-openpgpkey-03

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jun 2015 21:41:08 +0100

Hiya,

I've done my AD review of this one too. In this case I do
have a few questions I'd like to chat about before starting
IETF LC, four of 'em actually;-) But they should be quickly
dealt with.

And of course I've a bunch of nitty comments too, below,
but those can just be handled as last call comments.

Cheers,
S.

Stuff I'd like to chat about before starting IETF LC:

(1) Given the email-addr-in-DNS issues with this, would
this not be better as experimental? I think the WG did
consider that, but I forget, and in any case even if you
did, I want to ask again, to be sure to be sure:-) My
concern is that we not end up arguing against other
folks who may want to standardise some form(s) of key
server on the basis that this is *the* standard way to
do it. One way to handle that would be for this to be
experimental and for us to see if it gets deployed or
not. Another could be to just say in the text that this
proposed standard is one way of distributing keys, but
that others can be equally valid.

(2) The intro is very wordy. It could really lose the
editorialising generally. (Various examples below.)
Is that fair comment? Are the opinionated bits really
needed in the RFC?

(3) Can you briefly convince me that sections 2.1 and
2.2 are sufficient to write interoperable code.  Section
5.5.1.1 of 4880 does not seem to be the right place at
which to point for that, to me. But I've not implemented
PGP so I may be wrong.

(4) 6.2 still refers to sha-224, which is wrong now
isn't it?

---- detailed comments/nits/etc.

- intro: HKP needs a reference

- intro: "Worse, ..." the value judgement isn't needed.
Say (exactly) why it's worse or say nothing. And the
IETF does not have consensus that TOFU is "worse" unless
you say what it is "worse" than.

- intro: "have no method" - how do you know? It could be
they make no claims of validating things but that they
do internal stuff, who knows.

- intro: lack of secure lookup does not "prevent"
encryption, that's just wrong. I send encrypted mail all
the time without that.

- intro: "forcing...unencrypted" is also wrong given
S/MIME - while this is about PGP, please don't deny
reality.

- intro: "This document describes..." - you could delete
almost all the text before this para. And some after
it;-)

- intro: "Trust Signature model" needs a reference

- intro: "otherwise have to be" is false (same as above)

- Appendix A: This would be much better work a worked
example, incl. a public key one could import to
re-generate the outputs required.

- section 3: do you really need 28 octets? wouldn't
fewer be good enough and not risk collisions? Just
wondering.

- 4.2 - that MUST fail if local/DNS differ is a shame.
Did the WG consider adding a label or key version to the
RR that might allow for some update cases to work?

- section 5: is "recommended" there meant as a 2119
thing? If so, it's usually better in uppercase.

- 6.2 - in theory using the mail author's email address
might not mean publishing that I guess. But your text is
fine as-is, just noting that possibility.

- 6.3 - what if an application has no user? Does this
section apply then?

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 09 Jun 2015 13:13:56 +0200

Hello Stephen,

thank you for your extensive coverage of the draft.

> that others can be equally valid.

Even experimental seems a bit strong for a lookup method that has seen 
so much debate without serious improvement. The hashing method is poorly 
specified, and stronger text would not help - we are still preventing 
lookups in case of lower/uppercase differences, subadresses (peter+foo), 
dot insertion (gmail).

Let me emphasize that: the draft is, in its current form, undeployable 
for Google Mail. While I don't expect that they want to, this is a 
strong signal that the draft is broken.

I have strong objections to the texts "Both of these issues have been 
refuted" and "There is not much more we can do at this point to address 
it." under question 6 in 
http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shepherdwriteup/; 
similar "this is the best we can do"-language in other sections seem 
equally wrong. I also never got the feeling that WG consensus on the 
full content of the draft was "strong" but I may be mistaken here.

Better methods than hashing have been proposed. For example, split 
base32 is better in every way (and, as a bonus, actually deployable, 
unlike the hashing method) except perhaps address privacy concerns 
(which the draft explicitly dismisses in section 6.2 anyway). However, 
the split base32. has been shot down because, and I quote, "I do not 
understand the advantage of base32 in the QNAME." No other arguments 
have been put forward.

Moving the draft forward in its current form, onto Standards Track, 
would be a mistake. Moving it forward as Experimental would be somewhat 
better, but I suggest using even stronger language explaining that this 
RFC only defines an RRtype, keeping the lookup mechanism as no more than 
a weak suggestion.

While personally I feel split base32 would be fine to use in an RFC (be 
it Experimental or Standards Track), your point of 'not end up arguing 
against other folks' is valid, and in that case one could consider 
removing all lookup text from the RFC, and making it just about the 
RRtype.

> thing? If so, it's usually better in uppercase.

The mention of TCP here, as in 6.1, is a weird operational sidestep for 
this document. DNS operators know about big records and responses, and 
can deal with them accordingly, without singling out specific RRtypes.

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Jun 2015 09:50:53 -0400 (EDT)

On Tue, 9 Jun 2015, Peter van Dijk wrote:

> Even experimental seems a bit strong for a lookup method that has seen so 
> much debate without serious improvement.

Actually, the improvement has been to no longer require multiple records
to support Uppercase'ed email addresses often accidentally created on
virtual keyboard devices. This change came after a lot of discussion on
the list and in person at the last IETF, both in the dane meeting and
outside of it. It seemed (to me) the consensus was that the lookup
problem was a separate problem that could be solved by SMTP protocol
extensions, but that such extension should not be defined by this
document.

> The hashing method is poorly specified, and stronger text would not help

I think you actually mean to say you do not like the hashing method. The
specification itself is very carefully and clearly specified. If you
feel it is poorly written down to its intend, please supply a suggested
text change for us to consider.

> - we are still preventing lookups 
> in case of lower/uppercase differences

Some of the SMTP/Email folks said themselves that case sensitive mailboxes
do not exist in real life, only in historic RFC specifications. To
complain about not supporting PAUL being different from paul is not very
different from not supporting UUCP !bang addresses, which are technically
still valid email address formats.

The confusion that [email-masked] is not [email-masked] is in itself
a problem much larger than not finding the 'right' crypto key for
[email-masked]

>, subadresses (peter+foo)

Nothing prevents you from adding an OPENPGPKEY for hash(lower("peter+foo"))

You are prevented from making things up on the fly without backing up
the thing you just made up. Well, what would people do when they see
[email-masked] leading to a PGP key which only has
[email-masked] on it? How can I know those are not actually two
different peter's? Supporting +wildcarding just moves the problem.

> , dot > insertion (gmail).

Nothing prevents you from adding an OPENPGPKEY for hash(lower("[email-masked]))

You are again prevented from making things up on the fly without
backing up the thing you just made up. It relies on humans making
a decision that there probably are not two peter's at powerdns.com,
assumptions that cannot be made for email domains like gmail or yahoo.

> Let me emphasize that: the draft is, in its current form, undeployable for 
> Google Mail.

I fail to see that. What I see is that mailbox auto expansion has a
problem very similar to the public suffix problem. It depends on human
knowledge that is not made available reliable for automated tools.
Still, google could add openpgpkey records based on the rewrite rules
only they and their customers know about.

> Better methods than hashing have been proposed. For example, split base32 is 
> better in every way

Can you explain that, because I do not see that.

Let's say we would use chopped up base32 without lowercase without
hash. How would Google Mail be able to support [email-masked]
or [email-masked] better? They still need to either get from you
a list of permutations to generate many records, or you still have to
have logic on the client stripping out things sending multiple queries,
and then it won't matter whether the attempts are for hashed or split
base32. How would clients know that peter+foo is or is not the same
mailbox as peter?

The problem is the sender using made up things and forcing the receiver
to depend on a human to determine that some local part is or is not, the
same person. This draft does not pretend that problem is solvable.

> (and, as a bonus, actually deployable, unlike the hashing 
> method)

Odd statement, as fedoraproject.org and mail.de have deployed this.

> Moving the draft forward in its current form, onto Standards Track, would be 
> a mistake. Moving it forward as Experimental would be somewhat better, but I 
> suggest using even stronger language explaining that this RFC only defines an 
> RRtype, keeping the lookup mechanism as no more than a weak suggestion.

That would be a terrible solution and reduce one of the key features
this draft solves - key discovery. It would also lead to interop
failures of developers who have "implemented" the document yet only
implemented it partially.

> The mention of TCP here, as in 6.1, is a weird operational sidestep for this 
> document. DNS operators know about big records and responses, and can deal 
> with them accordingly, without singling out specific RRtypes.

Unforutnately, most DNS amplification attacks are not the fault of DNS
operators who know what they are doing, and having an RFC reference to
point out broken and unwise behaviour makes it much easier to patch
broken implementations. I talked to various people about how much I
should put in, for example there are also issues about cache size and
using openpgpkey records to cause other records to be removed from the
cache, and especially after talking to Mark Andrews and Andrew Sullivan
it was clear that those considerations did not belong in this document.

If we have a better and generic RFC that goes in depth to the operational
issues of amplification and DDOS attacks, I could reference that document
instead. Unfortunately, I do not think such a document exist.

Paul

---

From: "John Levine" <[email-masked]>
Date: 9 Jun 2015 14:13:07 -0000

>strong signal that the draft is broken.

Don't forget the equally serious scaling problem.  

Since hashes aren't reversible, if you have a mail system with
100,000,000 users who have keys (not implausible considering the
current size of Gmail, Yahoo, and Hotmail), you have to precompute all
100,000,000 hashes before you can answer any queries.  If the records
are on average 3K, that's a 300 gigabyte zone file. The largest
existing signed zone file of which I am aware, the .COM TLD, is about
10 gb before signing.  I realize computers are getting faster every
day, but a design that requires static zone files an order of
magnitude bigger than any that exist now doesn't seem like a great
idea.

Different encodings could address this issue, too.

R's,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 11 Jun 2015 01:37:19 -0400

Peter, 

> On Jun 9, 2015, at 7:13 AM, Peter van Dijk <[email-masked]> wrote:
> 
> Hello Stephen,
> 
> Even experimental seems a bit strong for a lookup method that has seen so much debate without serious improvement. The hashing method is poorly specified, and stronger text would not help - we are still preventing lookups in case of lower/uppercase differences, subadresses (peter+foo), dot insertion (gmail).
> 

This is a strong statement, I have a problem with your word "preventing" .
My reading of the draft is that mail sender can perform the Hash() operation
on any name she/he has/guesses for the receiver, and looks each one up in until a match is found or the sender gives up. 
Right now we do not really know if this will scale, some think it will, some do not think it will thus the 
experimental status. 
The fundamental problem is the mess called "email addresses" we are not the right forum to solve that problem. 

> Let me emphasize that: the draft is, in its current form, undeployable for Google Mail. While I don't expect that they want to, this is a strong signal that the draft is broken.

Well another strong statement, while for scale reason I may agree with you. But google has shown over the years that they can address scaling issues in many different ways. So while they may balk at this one they may select another mechanism that makes no sense for small operators.
Just because we may suspect some operators may or may not be able to deploy something absent of a statement from them we are just speculating. 
John Levine in a followup message was trying to calculate the size of a gmail PGP zone file, and I agree with him it would be big but on-line signing like PowerDNS provides could address that issue, with a large backend DB. 

> 
> I have strong objections to the texts "Both of these issues have been refuted" and "There is not much more we can do at this point to address it." under question 6 in http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/shepherdwriteup/; similar "this is the best we can do"-language in other sections seem equally wrong. I also never got the feeling that WG consensus on the full content of the draft was "strong" but I may be mistaken here.

The chairs can only go by what they hear either in public or private when judging consensus. Most of the objections I heard during the discussion on this draft were related to output format of the Hash function rather than the technique of the hashing. 
In my mind that was addressed by the editor, If I’m mistaken I happy to correct myself. 

> 
> Better methods than hashing have been proposed. For example, split base32 is better in every way (and, as a bonus, actually deployable, unlike the hashing method) except perhaps address privacy concerns (which the draft explicitly dismisses in section 6.2 anyway). However, the split base32. has been shot down because, and I quote, "I do not understand the advantage of base32 in the QNAME." No other arguments have been put forward.

The argument here is hash has fixed length, the base32 encoding of long email name is broken into multiple tables. 
If email people tell us that that is better than what is proposes we will listen. 

> 
> Moving the draft forward in its current form, onto Standards Track, would be a mistake. Moving it forward as Experimental would be somewhat better, but I suggest using even stronger language explaining that this RFC only defines an RRtype, keeping the lookup mechanism as no more than a weak suggestion.

what the document status is not a big deal, RRtype needs a RFC. 

> 
> While personally I feel split base32 would be fine to use in an RFC (be it Experimental or Standards Track), your point of 'not end up arguing against other folks' is valid, and in that case one could consider removing all lookup text from the RFC, and making it just about the RRtype.

We had that discussion early on, and the argument was how do I find it was asked. So while a replacement of this document may define a better solution we do not at this point know if that exists. A failure of deployment would be a good indicator. 

> The mention of TCP here, as in 6.1, is a weird operational sidestep for this document. DNS operators know about big records and responses, and can deal with them accordingly, without singling out specific RRtypes.
> 

Good question I will leave this to the editor to address

> Kind regards,

Thanks for starting a good discussion now lets hope others chime in. 

	Olafur

> __

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2015 10:39:19 -0000

>Right now we do not really know if this will scale, ...

But we do know that it is absolutely forbidden by any normal reading
of the mail RFCs.  I am baffled that a design that is supposed to be
about security would include guessing addresses that might or might
not be the party to which you want to send your highly secure mail,
and that the WG has repeatedly rejected small changes that could solve
that problem.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Jun 2015 10:48:20 -0400 (EDT)

On Thu, 11 Jun 2015, John Levine wrote:

> of the mail RFCs.

Just like not supporting !UUCP email addresses is violating the mail RFCs?

The [email-masked] and [email-masked] being allowed to be different
mailbox targets is an 25+ year old artifact of VAX/VMS/Windows and my
university's cost savings of their ADM3a egg terminal lowercase ROM
purchase. And not a single actual deployment of it was demonstrated to
me in the three years we worked on this document.

>  I am baffled that a design that is supposed to be

I have answered this a few times already, but let me try again.

1) If you reply to a message, there is no lookup guessing as the address
    is known exactly.
2) If I give you my email address on a business card, there is no lookup
    guessing but there gould be typoes or brainfarts. Like accidentally
    sending to [email-masked] which is not under my control.
3) If you make up an email address in your brain from memory, there is
    a chance of error. (and an even greater one if you MUST remember case)

What we are talkng about here is 3) and that's an unsolvable problem to
begin with, seeing how many people tried and failed to add me to their
XMPP list as [email-masked] instead of [email-masked].

So while getting the domain completely wrong is a complete security
disaster, so is getting the local part. If you make up characters,
eg [email-masked] when I have given you [email-masked],
then if your software does not warn you, I can still accomodate you
by putting in multiple hashes with the dot(s). But that is NO DIFFERENT
from putting in several base32 entries to accomodate these.

The base32 split up actually gains you nothing.

Upon review by the WG, we did determine that any translations other than
case are too dangerous because they are not universal, and there is no
way you can query a domain for those policies. So any rewriting with +
or . or - substituation should not be done and the draft does not tell
you to.

Let me write of saying my dad and his girlfriend have an email address
of [email-masked], and that is NOT the same mailbox as
[email-masked].

You submitted a proposed draft for a "email address confirmation lookup
service". Once that is standardised we could look at adding support for
that. But as noted, it being outside of DNSSEC/DANE, and requiring an
SMTP (or otherwise direct link) to the target mail domain, I do not
think that is a very realistic extension that many people will be able
to actually use, with todays SMTP filters in place on behalve of the
anti-spam people.

Paul

> R's,
> John
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Jun 2015 16:08:59 +0000

> or . or - substituation should not be done and the draft does not tell

I agree with all of that.  If it is to be DNS, then hashing works
no worse than most other encodings.  Since IIRC we're not at liberty
to require case-insensitive matching, we can't just use the literal
localpart unencoded, and all encodings suffer most of the same
limitations.  Hashing is in many ways the least bad of the available
choices.

So the choices are:

   A. Use DNS (with hashed lookup keys)

   B. Use some other lookup protocol, with a secure service
      endpoint specified via DANE, but a service other than
      DNS handling the database lookups.

There are some advantages to each approach.  The main disadvantage
of not using DNS (B), is that no such service is readily available,
so new code would be required to implement it.

An argument for (B) would be much more effective if there were
running code for such a service that could be readily integrated
into various environments with pluggable database backends, extensible
canonicalization rules, ...

IIRC it was also pointed out that PGP public keys or SMIME certificaets
obtained for something other than the literal requested address
are not necessarily usable when the identity embedded in the PGP
key or SMIME certificate is different from the one requested.

In particular, trust-anchor certificate usages would run into
significant problems since name matching must still be performed
against the actual certificate or PGP key.

So it is not unreasonable to adopt the view that secure email
requires non-fuzzy peer identities, and that variant addresses
(more than case difference) can't leverage end-to-end encrypted
email without additional keys for each variant (or multiple
names in PGP or SMIME keys when possible).

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2015 00:12:03 -0000

>no worse than most other encodings.

As I'm fairly sure I described in detail before, base32 provides the
option of reversing the encoding at the server, looking up the local
part using whatever fuzzy matching the server wants to use, and
sending an appropriate response.  There's be no need to do any of the
ill-advised local part guessing that people seem to think is required.

You'd need a stunt server, but if you're publishing 100,000,000 keys,
you're not going to use BIND.

If you think that couldn't work, could you explain why not?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2015 00:57:12 -0000

>so new code would be required to implement it.

At the WG in Dallas, people familiar with mail ops seemed to think
that webfinger would be suitable.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Jun 2015 10:26:49 -0400 (EDT)

> that webfinger would be suitable.

And using another protocol/service such as webfinger does not need to
use the query mechanism of hashing and lowercasing, so I don't see
this as an objection to the currently drafted DNS query method which
opts to use the existing DNSSEC security without adding an additional
service that needs to be available, scallable, authenticated and
withstand email enumeration attacks.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Jun 2015 10:40:15 -0400 (EDT)

On Sat, 14 Jun 2015, John Levine wrote:

> sending an appropriate response.

This pretends that the server can read the human mind of the sender.

It's an equally insecure fuzzy matching logic, but now done at the
server side instead of the client side. How is [email-masked] going
to get matched by this server side? To me? to Paul Hoffman? To no one?
If the human starts making up email addresses, it could go wrong. The
client implementation can have a local policy to protect the user. For
example, enigmail shows a big red THIS MESSAGE WILL NOT BE ENCRYPTED
warning.

>  There's be no need to do any of the

You started the guessing part at the client's human. Whether you
outsource their lack of brain power to the email client or the email
server does not matter much - both are insecure and prone to continue
with its human error.

> you're not going to use BIND.

Why don't we let those people speak for themselves if they want to?
It seems those with 100M accounts tend to know something about scaling,
and some of them even wrote a complete DNSSEC server implementation
backed by their own global database store.

> If you think that couldn't work, could you explain why not?

Using a red wax sealed envelope couriered by knight could also work.

It is just that this document of the dane working group is proposing
a solution that uses only DNSSEC, with the intension of not needing
to rely on other out-of-band protocols that can be firewalled, DDOSed
and in general do not have the resilience of a distributed DNS backend.
For example, the weeks long attack against pgp.mit.edu would be
something your solution would be equally vulnerable to.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Jun 2015 15:05:17 +0000

> This pretends that the server can read the human mind of the sender.

No, it assumes that the server has access to the same canonicalization
and aliasing data as the SMTP server that processes mail for the
domain.  If no such data is available then only exact matches will
return results.  With reversible encodings, the server might use
the DNS protocol, but use something fancier than exact match to
locate the right records.  Because it is the server for the target
domain, it might the canonical object corresponding to a given
lookup key.

One disadvantage of base32 is that it imposes new limits on the
length of the email address localpart, unless splitting into multiple
labels is introduced to handle longer inputs.  Hashing imposes no
such limits.

However, we're then still left with the problem of dealing with
certificates and/or PGP keys that don't match (via the enclosed
user identifiers) the email correspondent that the user asked for.
That requires new code in  user-agents to bind additional addresses
to an identity based on authenticated responses that return a key
for Y when you asked for X.

By now many of you have likely noticed that I'm on the fence on
this issue.  I have sympathies for both points of view.

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 14 Jun 2015 11:08:50 -0400

> This pretends that the server can read the human mind of the sender.

No, it does not.  Gratuitous insults like this are not helpful.

> to get matched by this server side? To me? to Paul Hoffman? To no one?

Hmmn.  The assumptions in this paragraph are a bit much.

Having actually written mail servers, and written books about mail 
servers, and written a few stunt DNS servers, based on my personal 
experience it would not be unreasonably difficult to adapt a DNS server to 
use the mail server's address matching logic to find the account to which 
a local part actually corresponds so it can get the PGP (or whatever) key 
that goes with that account.  There's nothing insecure about this, it's 
resolving the local part according to RFC 5321, the same way a mail server 
does.  In your example, it's matched to whatever internal account 
[email-masked] corresponds to.

Yeah, it requires the DNS server and mail server to talk to each other, or 
at least share a database, but that's the price you have to pay if you 
want to force SMTP features into the DNS.

If you're saying you can't imagine how someone could do this, I won't 
argue but it doesn't impress me as a very good basis for protocol design.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Jun 2015 11:23:20 -0400 (EDT)

On Sun, 14 Jun 2015, Viktor Dukhovni wrote:

> domain.

But that's not what this is about. This is about the user typing in an
email address FOO and that address does not exist, and now some fuzzy
matching will happen for the client/server to map it to a valid address
with no guarantee that the user actually meant that target mailbox.

It does not even relate to crypto keys!

Then somehow, the crypto key lookup is can be enhanced by using base32
lookups so the server can return crypto keys?

If you try to send an email and use the wrong email address, it will
go to the wrong user. In our discussion, it will go encrypted to the wrong
user or in plaintext to the wrong user. How does having done a base32
lookup versus a hashed lookup make any difference?

> If no such data is available then only exact matches will
> locate the right records.

There are no "right records" when you email a non-existing, wrong
address you made up or typoed on. This has nothing to do with crypto
keys.

> Because it is the server for the target

And that could be a disservice to the user! Now the secret email you
meant to send me gets encrypted and delivered to PaulHoffman isntead
of PaulWouters?

If you want to do fuzzy localpart matching, go and fix that problem.
Once you have fixed that, and you can determine the True Local Part
of a human's intention, you can just pick up the crypto key from
the right location even when using hash(lowercase(True Name))

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Jun 2015 15:37:16 +0000

> with no guarantee that the user actually meant that target mailbox.

I think this assumption is part of the miscommunication in this
thread.  I don't think that's what being suggested.  Rather, users
may have lots of valid addresses, known to the receiving system as
being the same user and in fact too many to create a separate DNS
record for each one (as with user+<anything> address extensions).

So the question is whether it should be possible for the key server
server (DNS or otherwise) to recognize address *variants* (not
fuzzy matching).  There's nothing fuzzy here, server's domain,
server's matching rules.

> lookups so the server can return crypto keys?

Well with base32, the original input string is recoverable as-is,
and so the server can apply no rules and use the lookup key verbatime,
or it might canonicalize the key in some manner that makes for localparts
in the domain in question.

> go to the wrong user.

That's not the use-case under discussion.  Rather the concern is about
*variant* addresses, not *wrong* addresses.

> meant to send me gets encrypted and delivered to PaulHoffman isntead

You've got the wrong end of the stick there.  Were not fuzzy matching
"paul" to some random Paul.

We're talking about "v.dukhovni" and "vdukhovni" being equivalent
localparts for my Gmail mailbox and Google unequivocally knows this
is the case, but user agents composing email do not (or at least
should/must not).

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2015 16:08:48 -0000

>with no guarantee that the user actually meant that target mailbox.

I'm sorry, but this assertion is completely wrong, and suggests a
rather serious failure to understand how mail works.

When a mail server handles a locally addressed piece of mail, it maps
the local-part of the address into some sort of internal identifier.
The local identifier for FOO might be FOO or foo but it's as likely to
be user1234.  On my system, every case variation such as foO and fOo
is an equally valid name for the mailbox.  Something like foo+bar or
FOO-bar might also be a name for the same mailbox, or might not,
depending on how user1234 has configured her mail.  Only the mail
server knows how it resolves its local-parts which is why for 30 years
the spec has said not to guess.

The mapping from the local-part to the internal identifier is
completely deterministic, and completely opaque to anyone outside.
Hence the only way to make this crock work in the DNS is for the DNS
server to be able to (conceptually) look inside the mail server for
the domain to see what the rules for that domain are.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Jun 2015 12:10:27 -0400 (EDT)

> fuzzy matching).  There's nothing fuzzy here, server's domain,

Currently there is no mechanism where the server can advertise their
rewriting rules. So a client implementation _could_ query for the
key of [email-masked] and if that fails try [email-masked]
for those well known domains we know the rewriting happens, then
check within the pgp key data for some confirmation or prompt the
user.

However, I was told I could not even suggest this in the draft.

> in the domain in question.

The problem is that for those who use offline DNSSEC signing, this is
not an workable solution. And since the lowercase()ing would be removed,
it means those with offline signing now have to stuff their zone with
all possible lower/upper casing they think their users virtual keyboards
might slip by, and the only way out there is to basically do the same
thing as above, if you can't find split(base32([email-masked])) try
split(base32([email-masked])). Which I was told I could not even suggest
in the draft.

> is the case, but user agents composing email do not (or at least

Yes, the + and the . use cases are very wel understood and easilly
handled by the mail client doing the DNS lookup.

The draft as currently proposd works with offline and online signing.
And with the simple universally known rewrite rules can be made to
work to support the + and . alias rewriting.

The base32/split solution does not work with offline signing. And can
be made to work to support offline signing and Casing by allowing the
client to issue hash(original), then hash(lowercase) queries.

So pick one.

Paul

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2015 16:24:09 -0000

>labels is introduced to handle longer inputs.  Hashing imposes no

If you'll review previous messages on this very topic, I proposed a
base32 version that pads the local-part out to 64 bytes with 0xFF (a
byte valid neither in ASCII nor UTF-8), splits it in half, and base32
encodes those as <highpart>.<lowpart>.  This can encode any
local-part, and is trivial to reverse.  Since most local-parts are
less than 32 bytes, a minor optimization is to omit the highpart if
it's all FF.  You can't use a base32 or base32hex encoding exactly
like the one in RFC4648 since it uses = for padding, but you could
leave out the padding since you know how long the result is supposed
to be.

It's ugly, but so what?  Only machines are going to look at it.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2015 16:27:06 -0000

>rewriting rules.

Mail servers don't have rewriting rules.  They do have rules to map
local-parts into internal identifiers which may or may not be
local-parts.

Please review previous messages on this topic.  It would probably be
helpful to read RFC 5321.

R's,
John

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 15 Jun 2015 10:34:26 +0200

Hello,

> client to issue hash(original), then hash(lowercase) queries.

So let’s do this!

Allow the client to lowercase (initially, or as a fallback) - I think 
everybody agrees there is no harm in this *in practice*, then encode 
with split base32. This works for offline signing exactly as well as 
lowercase+hashing, but anybody who wants more (support for dot 
stripping, variant addresses, etc.) can *choose to* switch to online 
signing and get these benefits.

As for the argument “a key is no use if it does not exactly match the 
email address”:
(1) keep in mind that whatever lookup mechanism we agree on will be 
copied for SMIMEA and, with any luck, other future protocols as well
(2) with split base32, one *could* run a mail server that automatically 
issues keys/certs for variant addresses, broadening the scope of 
‘opportunistic encryption’ to variant addresses without requiring 
client changes
(3) clients *could* decide to trust the DNS server on the variant 
mapping

2 and 3 are not required, but it would be good to keep room for them. 
With split base32, we get this flexibility. With hashing, we lose it.

Note that this requires very little changed text in the draft. Replace 
hashing with split base32, leave section 3.1 (variants) as is (with MUST 
NOT). Maybe add some text there about server-side (online signing) 
variant mapping.

Kind regards,

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 15 Jun 2015 14:48:08 +0100

On 15/06/15 09:34, Peter van Dijk wrote:
> everybody agrees there is no harm in this *in practice*

What rules will you follow for UTF8 names?
-- 
Jeremy

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2015 15:30:24 -0000

>with split base32. ...

No, for two reasons.  One is that RFC 5321 clearly says that case
folding is forbidden, and the mail world is very big.  Every time I've
assumed, that regardless of what the spec says, nobody does something
any more, it turns out that someone still does, usually for a
perfectly sensible reason that hadn't occurred to me.  It is painfully
evident that few people in this discussion have any experience with
mail systems other than their own, and none with large (millions of
mailboxes), and generalizing from limited experience is never a good
idea.

Also, to point out the obvious, this is just guessing that the mailbox
associated with BOB@blah is the same one as bob@blah.  Once again,
it's putting a ten ton steel door on a cardboard box, as we too often
do, which is just bizarre for a spec that is intended to be about
security.

The other reason is EAI.  Billions of people write their names in
UTF-8, not in ASCII, and they are going to have EAI mailboxes with
UTF-8 names.  You cannot case fold UTF-8 unless you know what language
the name is written in, and often not unless you also know what
sub-version of the language, e.g., the rules for Canadian French are
different from the ones for French, Belgian, or Swiss French, and
often not even then.  There's stuff like traditional and simplified
Chinese characters which are equivalent except when they aren't, and
which is the canonical version is a highly political question.

As should be obvious, I think that trying to force mailbox names into
the DNS is a fundamentally bad idea, but the least bad way to do it is
a base32 encoding of the exact name to be looked up since, unlike the
other options, it at least allows for the possibility of a correct
implementation.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jun 2015 12:22:50 -0400 (EDT)

On Mon, 15 Jun 2015, John Levine wrote:

> folding is forbidden, and the mail world is very big.

And I have repeatedly asking for a single deployment where FOO != foo
and not heard a single answer back. On the other hand, virtual phone
keyboards autocapitalizationing is a real issue on about 4 billion phones.

> generalizing from limited experience is never a good idea.

So is generalizing everyone elses experience on this list too.

No matter how you feel about RFC 5321, the lowercasing is needed. So we
have two options. One is to let the client to two queries, the other is
to store the local part encoded using a lower case call. If you say no
to both, the RFC won't state anything about this, and all the software
will send lowercase queries. It is the least desirable end result.

> associated with BOB@blah is the same one as bob@blah.

Which 4 billion humans (give or take 1) and 4 billion phones assume.
If you _security_ depends on people remembering case differences, no
amount of encryption can save you. It is a hypothetical non-realistic
contrived use case for which I've repeatedly asked empirical evidence.

> which is the canonical version is a highly political question.

Someone with knowledge on what common virtual keyboards in those
languages do could help us and say if this is a problem, and if it is
required. One possibly solution is to only attempt lowercase on those
characters or languages where it makes sense, eg only on ASCII. Again,
the choice is to specify this in the RFC so everyone performs this
operational identically and we guarantee interoperability. Or we pretend
this problem does not exist, and every piece of software will do their
own lowercasing and we have interoperability issues.

> other options, it at least allows for the possibility of a correct

It is only the least bad way if you make the assumption that I've only
seen made by you. That case sensitive mailboxes exist in the real
(non-cardboard box) world.

Paul

---

From: Richard Clayton <[email-masked]>
Date: Mon, 15 Jun 2015 17:55:58 +0100

In message <[email-masked]>, Paul
Wouters <[email-masked]> writes

>and not heard a single answer back. 

here's one (and it took me about 5 minutes to find it...)

<http://www.sevenforums.com/browsers-mail/229536-yahoo-disposable-
address-case-sensitivity.html>

though you'll see that Yahoo decided it confused too many people and
changed it. But that's pragmatism by a large provider introducing a new
feature, not "fixing a bug" and certainly (and this is fundamentally
John's point) not "having to change my mail system which has been
working just fine for the last 30 years".

>seen made by you. 

John is an expert on email and so the other experts on email don't need
to correct him ... When (implausibly) he says something which is not
correct then you will see other email experts (of which there are a few
on this list, but probably not all that many) will undoubtedly chip in

>That case sensitive mailboxes exist in the real

-- 
Dr Richard Clayton                         <[email-masked]>
                                  tel: 01223 763570, mobile: 07887 794090
                    Computer Laboratory, University of Cambridge, CB3 0FD

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jun 2015 13:11:56 -0400 (EDT)

On Mon, 15 Jun 2015, Richard Clayton wrote:

> changed it.

So that describes a deployment where they _accidentally_ introduced case
sensitiveness and all hell broke lose and they fixed it. That only
argues in favour of the assumption that case sensitive different
mailboxes are dead.

> But that's pragmatism by a large provider introducing a new

openpgpkey does not modify email delivery at all for unmodified 30 year
old servers or otherwise. At most, the 30 year old mail server will not
receive as much pgp encrypted email as it could, had it stopped the
unwise deployment of FOO != foo for their local parts - which I believe
is still many times smaller than the autocorrect on virtual keyboard
problem on offline signed zones that is left unaddressed when a
lowercase() call is left out of this document.

> on this list, but probably not all that many) will undoubtedly chip in

I'll leave this item on how to contribute and reach consensus to the
chairs, but thank you for your public contribution of agreeing with
John.

Paul

---

From: Florian Kirstein <[email-masked]>
Date: Thu, 18 Jun 2015 19:22:20 +0200

Hi guys,

I've been silently following this whole process basically from the
beginning and I (hope I) read all arguments and understood them. It's
a difficult topic and most things can't be simply declared "right" or
"wrong", so I understand why there still are so many disputing
opinions.

But there are (mainly) two points, where I think the discussion has
taken a wrong path, focussing too much on SMTP and too little on
PGP.

First is the CaSe topic: yes, the RFCs are clear, a SMTP server is not
allowed to make assumptions about the interpretation of case on the
receiving end. But: we are not describing a SMTP server here. We are
describing a standard for PGP key LOOKUPS. I've been using PGP for 20
years (in 2 months my oldest used key reaches that age, it's 1248
Bit so I might have to revoke it some day though :) and I have never
encountered a case sensitive lookup. GPG for example (and thus mutt's
integration of it for lookup) ignores case completely when looking up
a key. Also all key servers I use ignore case when you search
for a email address. Both don't even offer an option for case sensitive
lookup.

And I really don't see and never have experienced a problem with it.
As discussed, technically it is possible to have mail servers which
route different cased addresses really to different people, but
even though it is RFC compliant to do so, in the real world it should
be avoided - setups where it happend were changed, as it is just too
error prone. It's a theoretical corner case.

On the other hand, people typing emails in "wrong" casing are more the
default than the exception. If we build a lookup mechanism that ignores
that, we make the same mistake again that has been made so many times
in the history of email encryption: ignore the people supposed to use it.
If we want more encryption to happen, the lookup has to work in real life
cases (no pun intended ;). And it has to work BETTER than the existing
key servers, not worse.

So: a strong PRO lowercasing before lookup (as it's already in the current
draft) from my side. If there still are security concerns: It would be possible
to add a text telling domain operators, who know they route different cased
addresses to different mailboxes, not to implement this standard for
obvious reasons %) Won't affect real life deployments anyway. 

The second point is the often discussed "fuzzy matching". As John pointed
out perfectly correct (that's why I chose to follow-up here):
> be user1234.

But that's again the SMTP side! When we look at PGP and the OpenPGP
standards, we find the term "email address" as part of the User ID.
You create PGP Keys for your email addresses, not for your mail accounts!

It is not totally uncommon for people to have user@ and user+private@
to be delivered into the same mailbox, but have different PGP keys
for it. On the other hand, if I really want people to encrypt mails
to my user+usenet199703@ address, I should also publish my key with that
ID included. The same goes for username@gmail and user.name@gmail. If both
are used in your email conversations, add both as User IDs to your key.
It's the only way the sender can know the key is intended to be used for
that address. It's also the reason, that in the web of trust you
don't sign keys as many people think. You sign the individual user
IDs with a key.

Coming back to the real world: I hardly see people use encryption on
such "modified" addresses, and if they do, then intentionally and with
a key for it. That's a topic outside the scope of this draft, the
important part is that we don't block such usage - and we don't. It's
easy to publish the same key under many labels.

So again: no objection to the current draft, we should not encourage
implementors to do fuzzy matching stuff, but we also don't have to plan
for it on the server side. It's the decission of a user which User IDs
he adds to his PGP key and for those it will be used. 

I have some more thoughts on other topics of the current discussion, but
that would be too much for this already too long to read post ;)

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 Rößner <[email-masked]>
Date: Thu, 18 Jun 2015 23:37:24 +0200

> that would be too much for this already too long to read post ;)

I can fully agree with every word that you said.

Please see „real“-world and make a difference between SMTP and PGP (or for me interesting: SMIMEA).

PRO: lowercase

Concerning different things like user@ or user+foo@, CNAME is an option that works. I have done some tests on the SMIMEA thing and I use several CNAMES for different email addresses that point to the same address and therefor to the same RR.

Sincerely

Christian

---

From: "John Levine" <[email-masked]>
Date: 18 Jun 2015 23:56:33 -0000

>Concerning different things like user@ or user+foo@, CNAME is an option that works.

You can certainly use CNAMEs for aliases, and they will work in tiny
examples.

Given that there are over 500,000 ways to spell my single
unexceptional gmail address, which doesn't even have anything like
+foo extensions, I would think that the scaling issues would be
obvious.

R's,
John

---

From: Florian Kirstein <[email-masked]>
Date: Fri, 19 Jun 2015 02:23:34 +0200

Hi,

> +foo extensions, I would think that the scaling issues would be
Indeed - at least if you want to use all those variants for encrypted
mail. But usually people don't make up which variant of your gmail
address to use. You decide that by publishing it or mailing from it.

And that's also how PGP works, that is what I tried to explain in my
possibly too long mail. You decide which of your addresses to add
as User ID to your public key. And those are the addresses people
should use to send you encrypted mail.

Therefore I see no need for the openpgpkey specification to deal with
address variations. That does not prevent anybody from inventing a
webfinger standard to canonicalize email addresses, which could be an
additional, usefull service. But from a PGP key lookup mechanism I
expect to get keys which have the email I am searching for as User ID. So
if you really want to use 500.000 variations of your address, it's
PGP that has the scaling problem. Try to sign such a key ;)

Greetings,
Florian

-- 
[*] sys4 AG

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2015 00:57:42 -0000

>additional, usefull service.

Well, of course, if people use a webfinger service, it'll return the
PGP key directly. for reasons that should be obvious.

R's,
John

---

From: Christian Rößner <[email-masked]>
Date: Fri, 19 Jun 2015 09:04:20 +0200

> Am 19.06.2015 um 01:56 schrieb John Levine <[email-masked]>:
> 

My argument was not for case-sensitive emails. It was for:

- different emails
- local parts with or without extension

All treated lowercase. Like real world

I do not understand this discussion. RFCs for SMTP. ok. That is one point. Just think about paper mail. Would you expect that a letter arrives at your home, if people write you name in different ways? Yes of course! :-) So why this theoretical discussion about things that nobody on earth does use. 

If I answer your mail here and I write [email-masked], do you expect it to arrive or do you say this is somebody else? I bet you expect the mail has to arrive in your mailbox and nowhere else. No matter what the RFCs say. You expect this mail to land at your mailbox.

So this is the reason why I say, local part for PGP and SMIMEA MUST be lowercase looked up.

:-)

Christian

N.B. sorry for my english. May sound harsh. Isn’t meant so.

---

From: Jacques Latour <[email-masked]>
Date: Fri, 19 Jun 2015 13:39:52 +0000

+1 & Florian hit the mail, uh, the nail on the head with real world use, we should start with a 'simple' PGP/DNS/SMTP solution and go from there.  I expect emails with all case variance of [email-masked] to land in my mailbox, and looked up in openpgpkey with [email-masked]

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Christian Rößner
> Sent: June-19-15 3:04 AM
> To: John Levine
> Cc: [email-masked]
> Subject: Re: [dane] AD review of draft-ietf-dane-openpgpkey-03
> 
> 
> I do not understand this discussion. RFCs for SMTP. ok. That is one point. Just
> think about paper mail. Would you expect that a letter arrives at your home, if
> people write you name in different ways? Yes of course! :-) So why this
> theoretical discussion about things that nobody on earth does use.
> 
> If I answer your mail here and I write [email-masked], do you expect it to
> arrive or do you say this is somebody else? I bet you expect the mail has to
> arrive in your mailbox and nowhere else. No matter what the RFCs say. You
> expect this mail to land at your mailbox.
>

---

From: "A. Schulze" <[email-masked]>
Date: Sun, 21 Jun 2015 22:35:48 +0200

Jacques Latour:

> I expect emails with all case variance of [email-masked] to  
> land in my mailbox,
> and looked up in openpgpkey with [email-masked]

Jacques,

That's the point: you EXPECT that. But John has the idea that this could fail.
I don't know all the details about UTF8SMTP or EAI, but I could  
imagine we see the world in ASCII.
Most of us have no daily expieriences with chinese or arabian.
And at least I could not deny *THERE* Lee@chinese may be an other  
Mailbox then lEE@chinese
because of some strange encoding that may exist.

Andreas

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Jun 2015 09:41:12 -0400 (EDT)

> I don't know all the details about UTF8SMTP or EAI, but I could imagine we 
> see the world in ASCII.
> And at least I could not deny *THERE* Lee@chinese may be an other Mailbox 
> then lEE@chinese

John brought up three issues.

1) Lowwercase might fail for non-ascii 
2) mailbox localpart guessing not allowed
3) mailbox/local part of different case might be different person

His proposal of not doing a lowercase() completely
ignores the problem of casing for ascii (and perhaps

I have asked for confirmation that 3) exists and received no real life
example. 1) could be further narrowed down to those languages where
this is only a problem for. But there is not much point to address that
if we cannot do 2) for dogmatic reasons.

So again, I propose one of:

1) Do the lowercase() in the lookup and figure out non-ascii case
2) Don't do the lowercase() in the lookup and allow the client to
    do the request without lowercase() first, then try again with lowercase()
    if not found - if possible in the language/encoding used.

If these are not accpetable, we're back at using a hash instead of
base32 split and it won't solve the "guessing" issue which the clients
will have to do.

Paul

---

From: James Cloos <[email-masked]>
Date: Mon, 22 Jun 2015 14:04:21 -0400

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

PW> John brought up three issues.

PW> 1) Lowwercase might fail for non-ascii 2) mailbox localpart guessing
PW> not allowed
PW> 3) mailbox/local part of different case might be different person

But as was mentioned OpenPGP is relevant, not SMTP.  And given that the
most common OpenPGP and keyserver – and probably all – implementations
are already caseless there is nothing wrong with following their lead.

This isn't just about email.  A large percentage of the sigs I verify
are obtained though methods unrelated to smtp.  Detatched sigs are quite
common, and OpenPGP is or can be used when sending short messages, such
as via xmpp, sip or even ss7.

Using dnssec as an additional – or in many cases the only – trust path
when verifying a sig can only improve things.  It is not a perfect trust
path of course, but it is better than nothing.

Given all of that, taking (base32 (utf8 (lc (localpart address)))) and
splitting it by – working with presentation format — putting a . every
N chars from the right seems like the ideal plan.  Unless reversibility
is undesirable.

I've written otherwise in the past, but only because I forgot that the
OpenPGP world is caseless.  And I did so because I only ever use and
only remember seeing miniscule addresses when dealing with OpenPGP.

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

---

From: "John Levine" <[email-masked]>
Date: 22 Jun 2015 21:58:15 -0000

>3) mailbox/local part of different case might be different person

This sort of misrepresentation of what other people have said is
extremely unhelpful.

Anyone interested in understanding the issues and dealing with them
can easily find out about them from the list archives.

R's,
John

---

From: Carsten Strotmann <[email-masked]>
Date: Tue, 23 Jun 2015 07:52:13 +0200

Hi,

John Levine wrote:
> It is painfully

I see interest in the email hosting market to implement the openpgpkey
draft. I know of email service provider that already have deployed the
openpgpkey draft, and others are prepared to go online once the draft is
stable or published as an RFC.

Adoption in the market is important, and for these providers with
experience with a large number of mailboxes, the draft seems to be "good
enough".

The openpgpkey draft, as it is now, is a better way to retrieve PGP keys
than we had before (keyserver, LDAP, http-server). It would be painful
to see the adoption of openpgpkey to slow down or die because of the
draft being stuck in discussion.

I'm in favor of advancing the current draft to RFC status (experimental
if needed), gain operational experience with deployments, and come back
for improvements if required.

Carsten Strotmann

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2015 15:05:23 -0000

>stable or published as an RFC.

That's quite surprising.  I've talked to the large providers, all of
whom were extremely unenthusiastic.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Jun 2015 15:57:45 +0000

> whom were extremely unenthusiastic.

I think this reflects a difference in attitudes between Germany
and the USA.  In Germany, there's been a noticeable interest in
and uptake of DANE for SMTP, and now some interest in DANE for
end-to-end email security.

In the USA, the large providers have been first and foremost rather
reluctant to implement DNSSEC, which then precludes all manner of
DANE technologies, including PGP.

As and when that changes, it might become more clear whether they
were dragging their feet on DNSSEC in general, or had specific
reservations about the localpart encoding for keys in DNS, or did
not want to vend user keys via DNS at all.

Can you be more specific about the concerns of the providers you
surveyed?  Are they planning to move forward with DNSSEC?  What
fraction of users do they expect to adopt E2E encrypted email?
Are any of them planning to publish a draft with a concrete proposal
for vending user end-to-end keys?

I would conjecture that at the scale of the USA, large scale changes
tend to be viewed as "turning the Titanic" challenges, and that
the providers are often loathe to tackle DNSSEC adoption.  Questions
of whether to then use DNSSEC in some manner for user keys are
rather downstream from that.

Note, I am still on the fence about whether user E2E keys should
be vended via DNS, or some service over TLS, with keys for that
vended via TLSA RRs.  As for hash vs. base32, if more providers
are likely to support base32, so be it.  The sticking point is
lower-case lookup, not whether the result is hashed or base32
encoded.

Yes, lower-case is a minefield for EAI.  And yet Firefox and Chrome
routinely downcase all the Cyrillic domains I've tried before
querying DNS.  Try:

    ГоДжи-чИа.Рф

I don't know what they do with other scripts.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Jun 2015 12:43:15 -0400 (EDT)

> whom were extremely unenthusiastic.

For all the obvious reasons.

Did you ask them if their reluctance was based on business rather than
technical implementation reasons?

Obviously most of the large email providers provide "free" email for a
reason, and if that email is all unreadable to them, their ad business
is affected negatively.

Another obvious unsolved problem is webmail and how you trust
cryptographic keys to a browser. Obviously the big players do not want
to stop their ad driven webbased mail service.

These are the same reasons why the "big messenger providers" (which
happen to be the same as the big email providers) also actively block
or do not support the use of OTR encrypted messaging. It has however,
not stood in the way of OTR being deployed widely.

large providers being unenthusiastic about end-to-end encryption is
exactly the reason others want to deploy this document - to keep their
privacy.

Paul

---

From: Florian Kirstein <[email-masked]>
Date: Tue, 23 Jun 2015 19:16:54 +0200

Hi,

> That's the point: you EXPECT that. But John has the idea that this
As I already wrote, I think the important part is that we implement
a new form of PGP key lookup, not a mail server. All current mechanisms
are case-insensitive, key servers as well as the gpg implementation. 

I have to admit I would not see a real reason why we could not allow or
better require a lookup to be done in original AND lowercased form,
as long as it is defined that the published record should or even
must be the lowercase variation. But if we want a clearly defined
version, lowercase still is in my opinion the best way. For ASCII
localparts.

> imagine we see the world in ASCII.
You don't have to go to China, also Europe has many non-ASCII characters.
But indeed, international email using UTF8 chars is really really
uncommon here. The same goes for Japan, they simply use ASCII.
I can't tell much about China, but they don't have upper and lower
case characters anyway.

I have NEVER seen a PGP key with UTF8 characters in the Cmail address,
but I admit, the standard as I understand it allows it. I am pretty
sure case insensitive comparision will fail there with the usual 
locale problems in the usual tools, and people using such addresses
are or will have to get used to it and work accordingly.

> And at least I could not deny *THERE* Lee@chinese may be an other  
As I said, the chinese don't have lower case characters. But of
course european countries like france or germany have, outside ASCII.
And UTF8 has other problems - there are multiple different binary
representations for basically the same string. Thats why RFC6530
recommends that mail servers expect localparts could be normalized and
people are advised to generate their addresses in normalized form in the
first place. It's not a MUST though, which means people can do stupid
things if they want to.

I think very few people have acutal experience with utf8 email, but I
would expect in that world, binary equivalence will be the main matching
system. 

So do we want to care for UTF8 in the current form of the draft? If yes,
my suggestion would be to clarify that the lowercasing is only to be
applied for ASCII addresses. utf8 addresses should be looked up in the
original form, and if that original form is not equivalent to the normalized
form that SHOULD be looked up additionally. 

On the domain owners side I would RECOMMEND (as the international mail
RFC already does) to use normalized utf8 for the address and thus for
the record - if that differs from the form used in correspondence 
it might be advised to also add a record for that form. Generally
people using such addresses should know (as people using other variations
like +something) which forms of their address might be used by others,
an not only add matching OPENPGPKEY records for those, but also
add those forms as User IDs to their keys! 

I REALLY would advise not to make this a show stopper to advance the
DRAFT in its current form, possibly adding some clearifications like
those above for handling non-ASCII addresses. UTF8 emails are very
uncommon today and it is hard to guess how they will be used, especially
how PGP will be used with them. Everything beyond binary match in unified
form (and in original form as backup) would be wild guessing - and
I really assume, IF utf8 emails will be in broader use somewhere (asia
most probably I would guess) people won't enter them manually anyway,
so nothing beyond normalization should happen to it.

Greetings,
Florian

-- 
[*] sys4 AG

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2015 15:44:32 -0000

>surveyed?  Are they planning to move forward with DNSSEC?

They're planning to do DNSSEC.  Giant zones of hashed names that
don't have local-part semantics, not so much.

At least one of them said it'd make more sense to do it with
webfinger.

>the providers are often loathe to tackle DNSSEC adoption. 

You would be mistaken.  To point out the obvious, the operator of the
largest mail system also runs the 8.8.8.8 public DNS resolver, and it
does DNSSEC just fine.  They are also the registry for a bunch of new
TLDs which are required by contract to support DNSSEC from day 1.

R's,
John

---

From: Florian Kirstein <[email-masked]>
Date: Tue, 23 Jun 2015 19:52:21 +0200

Hi,

> As for hash vs. base32, if more providers are likely to support
> base32, so be it.  The sticking point is lower-case lookup, not
> whether the result is hashed or base32 encoded.

Full ack! I must admit I personally would prefer hashing for its
simplicity, chopped sha256 really is easy to implement in basically
all languages including shell scripts. The need to split some localparts
in two records adds complexity and I don't see the benefits.

But I don't have real objections against base32, as long as the tolower()
part remains. To have the full benefits base32 might have over
hashing, I think the additional lookup of the original form would have
to be a MUST then, so people really wanting to implement some clever
lookup server side (which I currently dont really expect to happen,
it simply doesn't make sense as a PGP key has a fixed set of user
IDs and those should be the lookup targets, simple as that) can do so.

Regarding adding dots every few bytes: if people really fear big
Zonefiles that would be an option I also would not object. But again I
don't really see the problem it wants to solve, really big providers will
most probably do live signing on request... 

Greetings,
Florian

-- 
[*] sys4 AG

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2015 02:21:47 -0000

>most probably do live signing on request... 

In base32, live signing is pretty much a given since the data will all be
live from the mail server,

In hashes, you might want to do some back of the envelope calcuations
about how many CNAMEs you'd need to cover even a modest number of dots
and case variations.

Speaking of case folding, I note that nobody here seems to understand
UTF-8 and EAI.  Really, it matters.  If you think it doesn't, please
add a sentence saying "This specification MUST NOT be implemented in
any country where languages other than English and Hawaiian are in
use" since those are the only ones that can be written in ASCII.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jun 2015 03:46:30 +0000

On Thu, Jun 25, 2015 at 02:21:47AM -0000, John Levine wrote:

> UTF-8 and EAI.

That's a unnecessary over-generalization.  Some of us have read
enough of the 2003 and 2008 IDNA standards to have been grounded
in the various issues.  I've been involved in multiple discussions
on EAI implementation in a popular MTA.

My comment about Cyrillic was an observation of current practice
in major browsers with at least one non-Latin (though still European)
script, there are clearly some pragmatic choices being made at the
user-interface layer that would not be appropriate in most other
contexts.

Thus while MTAs, DNS servers, ... must not case-fold UTF-8,
user-facing software (such as a mobile phone or similar), where
users enter email addresses, might well have enough information to
do something sensible with mixed case input, and may allow users
to correct unwanted normalization (damn you auto-correct).

Of course the story is much simpler for IDNA domain names than it
is for EAI localpart addresses.  IDNA (2008) domains use a restricted
character set that does not allow for the existence of two distinct
valid domain names that differ only in case.

The corresponding isssue for local parts is much more difficult,
because email addresses are not expected to satisfy this constraint.

I might hypothetically have an email address of:

    [email-masked]

In which, when entered by a user into an EAI-enabled MUA, the domain
might be casually mapped to lower-case Cyrillic, but the wisdom of
a similar localpart mapping is much more questionable, and might
require user confirmation.

What this might mean for the draft under discussion, is that any
case-conversion might need to be user visible and not implicit,
and be a feature of the address input UI, and not the underlying
PGP key lookup mechanism, once the user settles on an input address.

We can sensibly discuss other approaches, without asserting that
everyone else present is clueless.  If I and/or others have the
wrong end of the stick, a more constructive suggestion would work
better.  This could be, lower-case lookup for ASCII only, or
could be lower-case lookup only with user confirmation, (feature
of MUA user-interface, not key lookup library), etc.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Jun 2015 09:53:01 -0400 (EDT)

> Speaking of case folding, I note that nobody here seems to understand

 	"This sort of misrepresentation of what other people [have said] is
  	 extremely unhelpful."

> Really, it matters.  If you think it doesn't, please

I'm at ICANN53 and talked to some of the people that are well versed
in EAI, such as Asmus Freytag, Hirofumi Hotta and Wil Tan.

There is apparently only one language where lowercasing can change the
meaning of a letter and that is Turkish (with the letter I)

Their recommendation was to only lowercase for ascii and to normalize
everything else, then hash (or base32/split)

Normalization seems to be a proper way of doing things. Some references:

https://tools.ietf.org/html/draft-dainow-eai-email-clients-00#section-5
https://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-08#section-2.2
https://tools.ietf.org/html/draft-klensin-net-utf8-09

So my suggestion is to recommend normalization and refer to
draft-dainow-eai-email-clients and draft-klensin-net-utf8

I still feel that using this ruleset, using a hash seems fine, but if
people really feel that live signing DNSSEC servers talking to live mail
servers is a thing that must be supported instead of that use case being
handed of to a separate webfinger document, I could go with base32/split
as well.

I'll try to run into Warren again here at ICAN and see how and when he
would like me to update the document.

Paul

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Jun 2015 15:28:38 +0100

Hi Paul,

On 25/06/2015 14:53, Paul Wouters wrote:
> draft-dainow-eai-email-clients

This draft has expired in 2008... I don't think it will ever be 
completed. So make the reference informative ("as specified in ...") and 
copy the text from it.

> and draft-klensin-net-utf8
>