Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>

From: E Taylor <[email-masked]>
Date: Sun, 14 Feb 2016 15:04:04 +0000

Hello,

For the record, I'd like to repeat some of the comments I made on the
-05 draft, to clarify my position on the lowercasing issue (in light of
recent deployment examples), and to list the few remaining typographical
/ consistency issues in the text of the document.

On the topic of lowercasing, it seems that there are still differing
opinions, and this is potentially reflected by the implementations that
now exist.  For example, the author has pointed out some examples of
clients which force lowercasing, and I've checked that Mail.de (which
supports adding OpenPGP key information to the DNS[0]) replaces
uppercase letters with their lowercase equivalent when choosing a
username at sign-up (so presumably store only an entry for the lowercase
version in the DNS).  The online tester at openpgpkey.info[1] (run by
Mail.de) also forces email addresses to lowercase before searching.

In contrast, Posteo.de has announced a "key search" feature[2] (as well
as allowing its users to add their key information to the DNS[3]) but
haven't mentioned lowercasing when searching (although I haven't
confirmed that they don't).  Also, the online DNS record generator at
huque.com[4] is case sensitive and produces an error message if it
detects a mismatch (even just on case) between the "PGP userid (email)"
specified and the UIDs in the public key provided.

My suggestion for a consensus, therefore, is that the draft recommend
that clients attempt the case sensitive lookup first, and then fall back
to a lowercase lookup if that fails (ideally informing the user that it
has done this).  For the rare situation where a user specifies an email
address with uppercase characters in, this will result in an extra
query, but in the rarer situation that the lowercase version doesn't
exist (or represents a different user) then this provides a worthwhile
security benefit.  Moreover, I think that if the draft doesn't mention
the possibility of lowercasing, then client implementers will either
force lowercasing out of habit, or make their software search for both
just to be sure, as I have outlined above.

[0]
https://mail.de/blog/2015-03-pgp-schluessel-ueber-mailde-dns-server-verbreiten/
[1] https://openpgpkey.info/
[2]
https://posteo.de/en/blog/new-posteo-webmail-interface-can-find-public-keys
[3] https://posteo.de/en/blog/new-posteo-public-key-directory
[4] https://www.huque.com/bin/openpgpkey

The more minor issues I list below:

* Section 1
"using either the HTTP Keyserver Protocol [HKP]    Alternatively, users"
"using the HTTP Keyserver Protocol [HKP].  Alternatively, users"

* Section 1
"Therefor, these keyservers are not well suited"
"Therefore, these keyservers are not well suited"

* Section 2.1.2
"to ensure that correspondents know about these earlier then expected
revocations."
"to ensure that correspondents know about these earlier than expected
revocations."

* Section 2.1.2
"Strip away all but the most recent self-sig for the remaining user IDs
and subkeys"
"Strip away all but the most recent self-signature for the remaining
User IDs and subkeys."

* Section 2.1.2
Missing "." at end of some bulleted sections.

* Section 4
"A client supporting OPENPGPKEY therefor MUST NOT perform"
"A client supporting OPENPGPKEY therefore MUST NOT perform"

* Throughout
"Web Of Trust" / "web of trust"
"Web of Trust" (or whatever the preferred convention is)

* Throughout
"Behaviour"
"Behavior" (if American English is required)

Best regards,
Edwin Taylor

---

From: John C Klensin <[email-masked]>
Date: Sun, 14 Feb 2016 12:17:34 -0500

Executive summary for those who don't like my long and detailed
messages: In order to accommodate the extended mailboxes
permitted by RFC 6530 etc., this spec allows non-ASCII
addresses.  However, the use of almost-arbitrary Unicode strings
(in UTF-8) introduces issues of ambiguity in lower casing and
normalization, issues that are not addressed by either the
document of Edwin's proposal.  The document itself appears to me
to be unacceptable, even for publication as a recommended
experiment, unless those issues are addressed.

Details inline.

--On Sunday, February 14, 2016 3:04 PM +0000 E Taylor
<[email-masked]> wrote:

>...
> On the topic of lowercasing, it seems that there are still
> differing opinions, and this is potentially reflected by the
> implementations that now exist.  For example, the author has
> pointed out some examples of clients which force lowercasing,
> and I've checked that Mail.de (which supports adding OpenPGP
> key information to the DNS[0]) replaces uppercase letters with
> their lowercase equivalent when choosing a username at sign-up
> (so presumably store only an entry for the lowercase version
> in the DNS).  The online tester at openpgpkey.info[1] (run by
>...
> My suggestion for a consensus, therefore, is that the draft
> recommend that clients attempt the case sensitive lookup
> first, and then fall back to a lowercase lookup if that fails
> (ideally informing the user that it has done this).  For the
> rare situation where a user specifies an email address with
> uppercase characters in, this will result in an extra query,
> but in the rarer situation that the lowercase version doesn't
> exist (or represents a different user) then this provides a
> worthwhile security benefit.  Moreover, I think that if the
> draft doesn't mention the possibility of lowercasing, then
> client implementers will either force lowercasing out of
> habit, or make their software search for both just to be sure,
> as I have outlined above.

Temporarily and for purposes of discussion, assume I agree with
the above as far as it goes (see below).   Given that, what do
you, and the systems you have tested, propose to do about
addresses that contain non-ASCII characters in the local-part
(explicitly allowed by the present spec)?  Note that lowercasing
[1] and case folding are different and produce different results
and that both are language-sensitive in a number of cases, what
specifically do you think the spec should recommend?  

Also, do you think it is acceptable to publish this document
with _any_ suggestions about lower-casing or "try this, then try
something else" search without at least an "Internationalization
Considerations" section that would discuss the issues [1] and/or
some more specific recommendation than "try lowercase" (more on
that, with a different problem case, below).

Dropping that assumption of agreement for discussion, I
personally believe that this document could be acceptable _as an
Experimental spec_ with any of the following three models, but
not without any of them:

 (i) The present "MUST not try to guess" text.

 (ii) A recommendation about lowercasing along the lines
	you have outlined but with a clear discussion of i18n
	issues and how to handle them [2].

 (iii) A clear statement that the experiment is just an
	experiment and that, for the purposes of the experiment,
	addresses that contain non-ASCII characters in the local
	part are not acceptable (note that would also require
	pulling the UTF-8 discussion out of Section 3 and
	dropping the references to RFC 6530 and friends).

To be sure I understand what you are suggesting and save a
separate note, neither the EAI specs (RFC 6530 et al.) nor the
text in section 3 of the current document specify that
local-part strings are required to be normalized.   For such
strings, even when they are entirely in lower case when
presented by the user, there may be multiple different forms,
e.g., 
   U+0066 U+006F U+0308 U+006F   and
   U+0066 U+00F6 U+006F
are perfectly good (and SMTPUTF8-valid) representations of the
string "föo"    

Using the same theory as your lower case approach, would you
recommend trying first one of those and then the other [3]?

The more I think about it, the more I'm convinced that the
specification and allowance for UTF-8 [4] in the first bullet of
Section 3 is unacceptable without either text there that much
more carefully describes (and specifies what to do about) these
cases or an "Internationalization Considerations" section that
provides the same information.  I suggest that anyone
contemplating writing such text carefully study (not just
reference) Section 10.1 of RFC 6530.   Of course, simply
excluding non-ASCII local-parts from the experiment, as
suggested in (iii) above, would be an alternative.  I have mixed
feelings about whether it would be an acceptable one for an
experiment.  I am quite sure it would not be acceptable for a
standards-track document when the EAI work and/or the IETF
commitment to diversity are considered.

john

[1] For the benefit of those who are blissfully unaware of these
problems and sticking to Latin script as an example, consider
the the lower case form of "A".   Define "lower case form" as
characters that can produce "A" under at least some
circumstances.  The examples toward the right are less likely
than those to the left, but all are lower case forms for "A".
   a à á â ã ä

If that example doesn't cause either an insight or an adequately
bad headache, consider the lower case possibilities for "I",
including whether they are dotted or dotless and that either the
dotted or dotless forms can appear in combination with some of
the diacritical markings above.

[2] I note that, historically, the DNS community has been very
reluctant to accept techniques that depend on or imply multiple
lookups for a single perceived object and, separately, for
"guess at this, try it, and, if that does not work, guess at
something else" approaches.  Unless those concerns have
disappeared, the potential for combinatorial explosion when
lower-casing characters that may lie outside the ASCII
repertoire is truly impressive.

[3] In case it isn't clear, while "föoēy" has only one NFC and
one NFD form as a string, if unnormalized forms are allowed, it
would imply the potential for up to four lookups, not two.

[4] Nit: "encoded in UTF-8" is not actually a sufficient
statement.  The correct statement would be similar to "Unicode
encoded in UTF-8".

---

From: E Taylor <[email-masked]>
Date: Mon, 15 Feb 2016 08:36:36 +0000

Hello,

Thank you, John, for your detailed comments on the i18n aspect of this
draft, which I admit I hadn't fully considered.  I think you're right
that, whatever approach is taken, it would make sense to add a short
"Internationalization Considerations" section to state what the expected
interaction is between this specification and non-ASCII addresses.

> specifically do you think the spec should recommend?  

I have not seen any specific examples of software which unintentionally
converts characters to uppercase (although I can readily imagine such
bugs/features), so I'm prepared to assume that the lowercasing logic can
be safely limited to just the input strings which include only ASCII
characters.  My idea was for the client to make a reasonable effort to
correct for a plausible (but rare) problem, so for the purposes of an
experiment I think it is acceptable if this correction does not try
anything more clever, like converting [email-masked] to
[email-masked] (although [email-masked] should
be tried).

> that, with a different problem case, below).

You are right that adding such a section could be of great benefit to at
least some implementers, even if the discussion in that section is
simply "Only try lower-casing when the input is all ASCII".  If someone
can come up with something more helpful than that brief statement, then
I'd be very supportive of it.

> 	dropping the references to RFC 6530 and friends).

Perhaps you would settle for an option (ii.v) which is my lowercasing
recommendation + a discussion of the i18n issues + that discussion being
based on the experimental restriction of only applying the lowercasing
logic to ASCII-only local parts.  I hope that would be in keeping with
your sensible suggestions above.

> recommend trying first one of those and then the other [3]?

That is tempting, but I accept that it may be too much unnecessary
complexity to suggest or recommend it at this stage of the experiment. 
I know that various ideas have been proposed for handling normalisation
of local-parts more generally, and I think we should allow that work to
progress separately, uncoupling it from the document at hand.

> commitment to diversity are considered.

I think that excluding non-ASCII local-parts from just the extra
lower-casing logic, and pointing out the complexity of case handling in
non-ASCII contexts in a separate section as you have suggested, might
address the outstanding concerns, without hindering diversity.

> repertoire is truly impressive.

That's another reasonable point, thank you.  Hopefully it is mitigated,
at least for the most part, by settling for only lower-casing characters
for all-ASCII local-parts, avoiding the combinatorial explosion you
mention.  Also, this extra lower-casing step will only happen in the
relatively rare situations where the input local-part contains at least
one upper-case character (although I don't know in practice how many
extra lookups that will lead to, on average).

Best regards,
Edwin

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Feb 2016 16:33:55 +0100

> [email-masked] (although [email-masked] should

Note that the user understandability of "only lowercase if it's all
ASCII" is zero.

If ARNE matches arne, but BLÅBÆR doesn't match blåbær, any user from an
extended-ASCII country (which is *all* Latin script using countries,
even though the non-ASCII variants in English are rarely used) will be
mighty confused.

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Feb 2016 11:46:52 -0500

--On Monday, February 15, 2016 4:33 PM +0100 Harald Alvestrand
<[email-masked]> wrote:

> Note that the user understandability of "only lowercase if
> it's all ASCII" is zero.
> 
> If ARNE matches arne, but BLÅBÆR doesn't match blåbær, any
> user from an extended-ASCII country (which is *all* Latin
> script using countries, even though the non-ASCII variants in
> English are rarely used) will be mighty confused.

Indeed.

However, that is exactly the decision we made with IDNA (both
the "2003" and "2008" versions and, as there, may be
justification for really strong advice for treating email
addresses (both local and domain parts) as lower-case only.   

Harald, I am confident you know all of this, but others may
not...  The idea of requiring that mailbox names be treated as
all lower case was discussed during the work leading up to RFC
1123 and again in DRUMS (pre-2821).  The community reached what
appeared to me as fairly strong consensus that we just couldn't
do it.  Part of the problem was that, at the time 821 was
written (and maybe as late as the time of DRUMS) there were
still systems around that operated upper-case-only and had only
the vaguest idea what lower case was.  Another part was that
Unix (and Multics) and some of their successors were very
case-sensitive in general: "foo" and "Foo" and "foO" were
unambiguously three different names.

Because of that history and consensus, the strong suggestions in
5321 are about as far as one is going to get as far as
restrictions/ recommendations on the mailbox names themselves
and the "don't try to guess" rule probably isn't going anywhere.

In retrospect, we dodged a bullet because, for mailbox local
parts, ARNE does not, in terms of anything a sender is allowed
to predict, match arne.  That BLÅBÆR doesn't match blåbær
may still be a surprise to some, but it is not more or a
surprise.

>From that perspective, the problem facing DANE is that either
the basic "if they are not identical, they don't match" rules is
applied or there is a need to invent rules different from the
email rules and that de facto modify the email rules by
restricting the syntax of a mailbox if there is any possibility
a DANE DNS record will be used with it.  Nothing I'm aware of
(other than probably the WG Charter) prohibits DANE from
proposing an update to 5321 and 6530ff, but the history (and
probable side-effects that no one has tried to analyze) predicts
that the idea won't easily get community consensus.

     john

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Feb 2016 18:46:13 +0100

> that the idea won't easily get community consensus.

Yep. I'm sympathetic to the quandary of DANE.

Our strong advice was basically "if you (the recipient's mailbox
manager) depend on case  differences to tell mailboxes apart, you are a
fool; if you (the sender) depend on case not mattering, you are a bigger
fool."

DANE is an algorithm for the *sender* to look up information about the
*recipient*'s mailbox in the DNS, which means that the whole experiment
depends on the sender (who has no idea of what or where the recipient
is) being able to construct exactly the same hash that is generated by
the recipient - incompatible with the two pieces of advice I have
abstracted out above.

A possible way out (strawman!!!!) would be to say:

- All recipient participants in the experiment MUST agree to ignore case
differences in mailbox names. This has no effect on non-participants, so
we can possibly get consensus for that.

- All code in the experiment MUST use a particular algorithm to generate
the LHS lookup key
(I would suggest toLowerCase(NFC(string) in the C locale) off the top of
my head - but one could also argue for caseFold(NFC(string)) or
NFC(caseFold(string)) - and the people choosing had better know the
difference)

The case operations referenced are in Unicode 8.0.0 section 5.18 - I
*strongly* recommend actually reading that chapter, and not making the
(invalid) assumption that calling toLower() in some random library will
actually do something compatible with this.

I don't think anything less precise has a chance of being interoperable.

BTW, this text from the draft is obviously not saying what it intended
to say:

   o  The user name (the "left-hand side" of the email address, called
      the "local-part" in the mail message format definition [RFC5322]
      and the local-part in the specification for internationalized
      email [RFC6530]) 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 and then hashed using the SHA2-256 [RFC5754]
      algorithm, with the hash truncated to 28 octets and represented in
      its hexadecimal representation, to become the left-most label in
      the prepared domain name.  Truncation comes from the right-most
      octets.  This does not include the at symbol ("@") that separates
      the left and right sides of the email address.

As written, it states that hashing is only applied to strings that are
not originally in UTF-8 - but the "for example" text below makes it
clear that this is not intended.

Replacing "and then" with ". The string is then" would fix the problem.

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2016 19:13:08 -0000

>may still be a surprise to some, but it is not more or a

But MTAs can and do treat local parts any way they want.  Do EAI MTAs
do this sort of langauge-sensitive mapping on incoming non-ASCII
addresses?  There's no reason they can't, and the advantages of doing
so are obvious.

I can see problems where systems are large enough to be used by
recipients that speak multiple languages, but I'd think that it can
usually guess what language a mailbox is in, or it can just ask when
the address is created.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2016 19:29:03 -0000

>the recipient - incompatible with the two pieces of advice I have

You know, this is a self-inflicted wound.  Had they asked people in
the e-mail community while designing this hack whether it is a good
idea to map mailbox names into the DNS, the unanimous response would
be that it never has worked in the past, and it's not going to work
any better now.

There are perfectly reasonable ways to do DANE-secured lookups of
mailbox keys.  A simple one would be a per-domain SRV or URI record
that points at an RFC 4387 key server, with its certs secured by TLSA.
It's just as secure, just as DANE-ful, and has none of the semantics
and scaling problems of trying to shove mailbox keys into the DNS.
Its realistic security is better, since the mailbox names don't get
relayed through DNS caches of unknown snoopiness.

The endless debate about upper/lower case, and the continuing failure
to address the much greater actual range of mailbox semantics problems
should tell us to back up and look for something that really works.

R's,
John

---

From: [email-masked]
Date: Mon, 15 Feb 2016 11:45:00 -0800 (PST)

> NFC(caseFold(string)) - and the people choosing had better know the

I would strongly recommend that if you're going to do this, you do it using the
same case-folding and normalization algoritms that are used for IDNs. (You can
skip the prep stuff and punycode.)

My reasoning here is that if you have support for EAI you're likely 
to have IDN support libraries lying around. Libraries which may or may not
support other normalization and case-folding algorithms.

> actually do something compatible with this.

Whereas an IDN library will have something you should be able to trust.

> I don't think anything less precise has a chance of being interoperable.

Agreed.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 15 Feb 2016 16:04:30 -0500

> On Feb 15, 2016, at 2:29 PM, John Levine <[email-masked]> wrote:
> 

Sadly Keith Moore's addrquery draft seems to have stalled:

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

I agree that was a promising direction...  Yes I quibbled over
the details, but certainly not with the intention of blocking it,
rather I wanted it to be more realistically deployable...

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Feb 2016 18:14:21 -0500 (EST)

> clear that this is not intended.

That text is not quoted from the 07 draft, because 07 states:

    o  The user name (the "left-hand side" of the email address, called
       the "local-part" in the mail message format definition [RFC5322]
       and the local-part in the specification for internationalized
       email [RFC6530]) is encoded in UTF-8 (or its subset ASCII).  If
       the local-part is written in another encoding it MUST be converted
       to UTF-8.

    o  The local-part is hashed using the SHA2-256 [RFC5754] algorithm,
       with the hash truncated to 28 octets and represented in its
       hexadecimal representation, to become the left-most label in the
       prepared domain name.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Feb 2016 18:17:28 -0500 (EST)

> and the "don't try to guess" rule probably isn't going anywhere.

The failure of that community is pretty big and it is clear that the
(non)rules that came out of that failure are _still_ causing us problems.
It has itself delayed this 3 page document for over a year without
any substantial new input or insights.

Two problems we do not have:

1) [email-masked] has been delivered to [email-masked]
    since Network Solutions was the only Registry in town.

2) No sentient organisation hands out a LHS with only case differences
    to different entities (eg [email-masked] is realistically guaranteed
    to be [email-masked]).

I find any efforts rejecting a solution because it does not support
the above two corner cases to be an exercise in dogma rather than
engineering.

Two real problems we do have:

1) Phone virtual keyboards and language settings auto-capitalizing
    recognised names (probably a bigger problem in the US-ASCII world)

2) Browsers in webforms auto-capitalizing recognised names. (probably a
    bigger problem in the US-ASCII world)

I find any efforts ignoring these two things happen at an almost daily
rate for those people who use smart phones to be dogma instead of
engineering.

Then we have two contradicting requirements from the SMTP world:

1) One must only use the _exactly_ inputted local-part

2) One is not allowed to use more than 1 lookup or else it qualifies
    as "illegal local-part guessing"

While I can sympathise with the desire to support UTF-8, EAI and
everything else in the local-part, I have done my best contacting
people who were involved with EAI and to put their advised text
into the draft. If you have improvements to those texts, please
share them with us.

I have indicated I would be completely fine with saying anything from
"anything non-ASCII" should not be lowercased to "anything non-ASCII
should be lowercased using [ruleset donated by those people object to
the current text]" to "try unmodified, then lowercased". The only
unacceptable option to me is "try only what was input by user and
ignore all common problems associated with that".

So, please provide text for the preferred variant solution.

> Nothing I'm aware of

To put it bluntly, I'd rather commit to 800 hours of unsedated
dental drill work than to go anywhere near discussing RFC 5321
related items within the IETF ever again. But I would be happy
to watch the fireworks from far far away if you wish to take
on that work.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Feb 2016 18:21:39 -0500 (EST)

> be that it never has worked in the past, and it's not going to work

We did ask. Not only that, they attended one DANE meeting en masse.

> relayed through DNS caches of unknown snoopiness.

Please look in the DANE archive as to why this solution was rejected
before.

> should tell us to back up and look for something that really works.

This exact statement was said 1 and 2 years ago. If the people that
think this is a problem are not moving, then I don't think this
document should be held hostage to that process. in other words, go
do your local-part to DNS mapping and come back and a write a bis
document.

Paul

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Feb 2016 21:13:57 -0500

--On Monday, February 15, 2016 18:17 -0500 Paul Wouters
<[email-masked]> wrote:

>> Because of that history and consensus, the strong suggestions
>> in 5321 are about as far as one is going to get as far as
> It has itself delayed this 3 page document for over a year
> without any substantial new input or insights.

Paul,

You won't get agreement from many of us that it is even a
failure.  As I said in my earlier note, the decision by the
community (generally and email-specific) that senders are not
allowed to make assumptions that anything matches a mailbox name
other than the mailbox name itself has protected us from a
complete mess wrt internationalization (see Harald's example).
That same decision was critical to allowing gateways based on
Internet mail to work well with a wide variety of other email
systems, sometimes turning into the preferred transport between
islands of identical, but differently-configured, systems. FWIW,
the "no one but the delivery server gets to interpret an
address" rule of the applications layer application of the
robustness principle is the latter principle at its best, at
least until would-be senders starting reading the requirement to
be liberal about what is accepted as "recipients are 'required'
to accept whatever nonsense we throw at them".

I don't suggest that SMTP is perfect.  Most of us have some
things we would change if we were starting over today (as you
might guess, the rule about senders not interpreting address
variations is not on my personal list).  But Internet mail is on
the short list of our most widely-deployed and wildly-successful
protocols.   From my perspective, the very wide deployment of
SMTP/ IMF mail that makes it attractive to provide better ways
to secure it (if it were not deployed and in use, you presumably
wouldn't care) makes it incumbent on the DANE WG (and anyone
else proposing improvements) to design those improvements to
work well with the mail environment as the mail environment is
actually defined, deployed, and working.

If your position is, instead, that the email community screwed
up (or "failed") to produce a protocol specification that was
convenient for how you (and presumably the DANE WG) would like
to do things now, then mine shifts as well... from "if you folks
want to try an experiment to see how it works and how much it
deploys, then go for it as long as the spec is clear on
mechanisms and assumptions" to "DANE is living in an alternate
reality and the IETF should not approve this spec, even as
Experimental, without a convincing demonstration that it will
not lead to damage to the mail system or to an increase in bad
SMTP implementations".

As John Levine points out, it is not as if there are no
plausible alternatives that would work at least as well or
better from an email (real SMTP email, as defined, implemented,
and deployed) standpoint.  In addition to the example he gives,
there is a possibility that has been discussed on and off for
decades.  That is to simply define an SMTP extension that builds
on the original motivation for VRFY and allows asking the
relevant delivery server (even in a multi-hop environment) if it
has a public key it would recognize as associated with a given
address and, if it does, what the canonical form of the address
is and what the key is.  There are issues with that too, but
they doesn't get us tangled up with the difference between DNS
and email comparison functions or require that we modify the
mail specifications and environment in order to make a
key-finding function work.

>     since Network Solutions was the only Registry in town.

Actually, there was controversy about that many years ago that
has nothing to do with Network Solutions.  That is why RFC 2821
Section 4.5.1 imposes a specific requirement that "Postmaster"
be accepted as case-insensitive.  IIR, case-independence for
Postmaster was widely assumed before 2821 but 2821 was the first
time the rule was specified in an IETF (or predecessor)
consensus document.  It is also clearly stated as a special
case, not a general comment about case-independence.

>     to different entities (eg [email-masked] is realistically
> guaranteed to be [email-masked]).

You may think so, but your position is not supported by either
the text in 5321/5322 (or their predecessors) or practice.   I
would agree that it is generally ill-advised, and would agree
with or make snarky comments about "security by obscurity" (and
have done so), but I've seen just that done, most often in cases
in which one form leads to different behavior than the other
even if both are accepted.  At least some of the reasons are
similar to some for using subaddresses: if one can match a
sender (backward-pointing) address to the particular stylistic
form that sender is expected to use, it is possible to easily
exclude a good deal of spoofed mail.     As to whether the mail
administrators or organizations who have done that are sentient,
I don't think that is a debate you want to have.

> the above two corner cases to be an exercise in dogma rather
> than engineering.

You are of course entitled to your opinion.  See above for parts
of the explanation of why some of us may not agree with you.

 
> rate for those people who use smart phones to be dogma instead
> of engineering.

But no one is "ignoring" either and the email specification were
not ignoring them even before there were phones with keyboards
or browsers.  That is one reason why the robustness principle
exists and applied to email.  More specifically, it is why 5321
was intended to be clear that it is generally wise for delivery
MTAs to accept mailbox local part name variations that users
would expect to work -- whatever those uses might think of as
case-independent matching included.  If they do that, then the
cases you mention above "just work".  But "generally wise" (and
even "SHOULD avoid" from RFC 5321 Section 4.1.2) are far from
"MUST" do things that way.

The problem with the dane-openpgpkey proposal isn't either of
the two cases you cite.  It is that it requires a sender to
guess at the form of a string that will be accepted by the
delivery MTA and, if the delivery MTA makes a distinction (one
that it is allowed to make) about a canonical or preferred form
of that string, what that is.

> 1) One must only use the _exactly_ inputted local-part

See above.  That isn't an SMTP requirement as far as SMTP is
concerned because the delivery MTA is free to accept any
variations it likes.  The prohibition is on guessing at
transformations of the local part in the originated MUA,
Submission Server, or intermediate MTAs and expecting that the
mail will still go through.

> 2) One is not allowed to use more than 1 lookup or else it
> qualifies as "illegal local-part guessing"

Not an SMTP requirement.  As far as SMTP is concerned, guess all
you like.  Some anti-spam, rate limiting, and other systems may
be fairly hostile to your doing much of that, but it isn't
"illegal", especially as far as SMTP is concerned.  There is
also, historically (much less used today but not deprecated), a
command that not only facilitates local-part guessing but
facilitates discovery of canonical names and/or preferred
forwarding addresses.  It is called VRFY and has been around
since RFC 821.

> into the draft. If you have improvements to those texts, please

I don't know who you contacted, but, as co-author of the
"framework" specification and co-chair of the WG at the time the
standards-track documents were completed, I don't think you
asked me.  The omission of the normalization issue --something
that was extensively discussed in the WG-- suggests that
whomever you did consult was either asked the wrong question,
was not paying adequate attention to the details, or that your
interpretation of the "advised text" did not fully capture their
advice.  I hope it is not necessary to dig further into those
details: the document text that is relevant is what is in the
document in IETF LC and that text is, at least IMO, insufficient
from an i18n standpoint regardless of how it got that way.
 
> unacceptable option to me is "try only what was input by user
> and ignore all common problems associated with that".

But the latter is, for reasons several others have explained
better than I can, the _only_ option that is consistent with
what SMTP allows a sender or an agent for a sender to do.  If
you don't like it, propose a modification to 5321.   More
specific objections to each of your preferred options have
appeared in earlier notes but the bottom line, for me, is that
your spec should either be fully consistent with the language
about address interpretation in RFC 5321 or it (or a
supplemental, normatively-referenced document) should try to
update and change 5321.

If neither consistency with 5321 nor updating 5321 is acceptable
to you and the WG, withdraw the document.

>> probable side-effects that no one has tried to analyze)
>> predicts that the idea won't easily get community consensus.
> 

To be equally blunt, absolutely no one in the community who has
been actively involved with the development of 5321 and its
application has come forward to support the changes you would
apparently like or to volunteer to do the work.  I won't presume
to speak for others but, at least in my case, that is in large
measure because I think those changes would be a bad idea.
Assuming you aren't going to change your attitude toward dental
drills or the solution that I believe is the only one that is
fully 5321-compliant and further assuming that you and the DANE
WG are sincere about this being an experiment, I suggest what
has been suggested before:

	(1) As Harald suggested, define the participants in the
	experiment so that any mailbox address or site that does
	not conform to whatever assumptions you want to make is
	simply excluded.
	
	(2) In addition, define the experiment as applying to
	all-ASCII mailbox names only so that SMTPUTF8-style
	addresses (and messages) are not supported and you don't
	need to figure out how to deal with this complications
	at this stage.

Going that route requires that you and the WG very clearly
recognize this as an experiment -- not just as a category of
RFC, but as a specification that will require more work and
almost certainly some substantive changes to be acceptable as a
Proposed Standard even if the experiment itself is judged to be
completely successful.  But that may be a reasonable choice.

best,
    john

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Feb 2016 11:07:29 +0100

>       hexadecimal representation, to become the left-most label in the
Oops - yes, I was reading -06. Good fix!

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Feb 2016 07:04:06 -0500

> rather I wanted it to be more realistically deployable...
It's not dead.   I'm still working on it and will try to get a revision 
out this coming weekend.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 16 Feb 2016 08:25:36 -0500

--On Tuesday, February 16, 2016 07:04 -0500 Keith Moore
<[email-masked]> wrote:

>> the details, but certainly not with the intention of blocking
>> it, rather I wanted it to be more realistically deployable...
> It's not dead.   I'm still working on it and will try to get a
> revision out this coming weekend.

This is great.   However, other than demonstrating that there is
an alternative, it doesn't seem to me to change the status of
draft-ietf-dane-openpgpkey-07 or the current Last Call at all.
Unless the DANE WG or the IESG want to pull that draft, the
availability, or even community acceptance, of
draft-moore-email-addrquery does not prevent their proposing an
experiment involving DNS-stored keys, nor does it reduce the
requirement that the community try to figure out what the
conditions are that would or would not make that experiment and
its specification acceptable.

    john

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Feb 2016 09:18:40 -0500 (EST)

On Tue, 16 Feb 2016, Keith Moore wrote:

> It's not dead.   I'm still working on it and will try to get a revision out 
> this coming weekend.

Unfortunately, the draft is useless for end-to-end encryption, as it
relies on a clean path from the client to the recipient's SMTP server
which is frequently blocked by ISP's and could be blocked more in the
future to prevent end-to-end encryption using this new RRTYPE.

This was explained in various discussions on the DANE list.

Paul

---

From: "John Levine" <[email-masked]>
Date: 16 Feb 2016 22:43:41 -0000

>relies on a clean path from the client to the recipient's SMTP server ...

I would encourage anyone interested in this topic to read the draft,
particularly section 4.  No, it does not depend on a clean path from
the MUA to the recipient MTA.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Tue, 16 Feb 2016 18:07:54 -0500

--On Tuesday, February 16, 2016 22:43 +0000 John Levine
<[email-masked]> wrote:

>> Unfortunately, the draft is useless for end-to-end
>> encryption, as it relies on a clean path from the client to
>> the recipient's SMTP server ...
> 
> I would encourage anyone interested in this topic to read the
> draft, particularly section 4.  No, it does not depend on a
> clean path from the MUA to the recipient MTA.

As I read it, it requires a path from the MUA or Submission
server that can be secured with TLS at each hop.   It does not
require a single hop arrangement.  Whether the first is a "clean
path" is a matter of definition, but the proposal certainly
appears to be workable for end-to-end encryption to me.

I have suggested, off-list, to Keith that, in preparing a new
version, he should carefully consider the tradeoffs implied by
the TLS requirement versus allowing any server that can be
reached (even multihop) by SMTP to return key and address
information.   As usual, the answer will probably depend on what
problem we are trying to solve and which aspects of it are most
important.

    john

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Feb 2016 22:24:42 -0500 (EST)

> the MUA to the recipient MTA.

    This section defines a service extension to the Mail Submission
    Protocol [RFC6409] which can be used by an authenticated, authorized
    client to query an SMTP server on port 25 for information about an
    email address.  This is intended only as a workaround for port 25
    blocking, so the extension is minimally tailored for that purpose.

So if my ISP is blocking port 25, I am forced to ask my ISP if the
remote party could accept encrypted email and to which key?

It is not "end to end" encryption, if the ISP can change the outcome.

So again, the above draft does not provide a workable solution for
the openpgpkey draft.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Feb 2016 22:38:08 -0500

> On Feb 17, 2016, at 10:24 PM, Paul Wouters <[email-masked]> wrote:
> 

[ That's only if your ISP is your submission server, in which case
they're also likely operating the zone that would public your
public keys, and you're likely vulnerable to a variety of attacks
via that ISP.  Since faking the keys of remote parties is likely
tamper-evident, and such faking can also happen by who-ever is
publishing the zone data on the other end, I think this is a
reasonable architecture, but we digress... ]

The addrquery draft is not under discussion here, so perhaps I
should not even have said that much.  Exploring additional
approaches seems reasonable.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 2016 08:42:49 -0500

Paul (and others),

There is no question that the email-addrquery draft needs work,
even the author has said so.  I've tried to start a thread on
the SMTP list that identifies some possible issues to be
examined.  If you want to have a constructive conversation about
that draft, please move it there.  Probably it would be best to
wait for the next draft and comment on it rather than attacking
-01.   

None of this is relevant to the proposed experiment advocated by
dane-openpgpkey unless you want to try to convert this
discussion into "dane-openpgpkey is no worse than
email-addrquery, therefore it should be approved".  I suggest
not going there because the IETF doesn't need to approve _any_
flawed protocol and, be being in Last Call, there is a claim
that dane-openpgpkey is finished and ready to go, a claim that
has never been made for email-addrquery.

I'll respond to your comment below if you want to make it on the
SMTP list, but suggest that the description of _any_
key-location or key-retrieval must mechanism be clear about the
difference between obtaining a purported key and determining its
validity for some intended use in order to be taken seriously.
This thread periodically seems to lose track of that distinction.

     john

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Feb 2016 00:12:51 +0000

> approaches seems reasonable.

Agreed. I think it might make sense to add a bit of text to all
the drafts in this space. Would something like the following be
useful to include in this and other similar drafts?

"This specification is one experiment in improving access to public keys
for end-to-end email security. There are a range of ways in which this
can reasonably be done, for OpenPGP or S/MIME, for example using the
DNS, or SMTP, or HTTP.  Proposals for each of these have been made with
various levels of support in terms of implementation and deployment.
For each such experiment, specifications such as this will enable
experiments to be carried out that may succeed or that may uncover
technical or other impediments to large- or small-scale deployments. The
IETF encourages those implementing and deploying such experiments to
publicly document their experiences so that future specifications in
this space can benefit."

Cheers,
S.

PS: Please note that this is separate from the lhs and other points
made about this draft.

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Feb 2016 01:31:31 -0500

--On Friday, February 19, 2016 00:12 +0000 Stephen Farrell
<[email-masked]> wrote:

> "This specification is one experiment in improving access to
> public keys for end-to-end email security. There are a range
> of ways in which this can reasonably be done, for OpenPGP or
>...

Stephen,

I think such a paragraph would be a significant step forward.  I
don't think it is a substitute for any of the drafts being clear
about known issues and security risks, including warnings (aka
"considerations") about the difference between obtaining a key
and authentication of the key vis-a-vis the supposed key owner.
I don't know whether you consider that separate from "...other
points made about this draft." or not.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Feb 2016 07:23:31 +0000

Hi John,

> points made about this draft." or not.

Yep, the intent is for this to be additional to whatever text may
be needed to handle specific points about the rest of the draft
content. So this doesn't touch on the lhs issue or others that need
separate consideration.

And comments are welcome on the specific text proposal as well,
esp if we want to include more or less the same words in the
various drafts in this space.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Feb 2016 08:58:31 -0500 (EST)

> publicly document their experiences so that future specifications in

I'm fine with adding this text to the Introduction.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Feb 2016 09:22:19 -0500 (EST)

> points made about this draft." or not.

I would feel it to be very constructive if we could focus on specific
text. We already merged in a bunch of text on request from the
openpgpkey-usage document to satisy the earlier requests for security
considerations.

Paul