Subject: Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd)

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Mar 2015 22:09:57 -0400 (EDT)

Wil Tan wrote:

(added the dane list in my reply)

Thanks for your review Wil.

> My comments on draft-ietf-dane-openpgpkey-02:
> 
> 1) Section 3, in case of EAI, it should specify the character encoding of
> the local-part on which to perform the SHA224 function.

That's a valid point. Should we say that it should be UTF-8 ? I will
add some text for this if I get a few more agreeing nods of people.

> 2) Section 3, it should probably reference RFC5322 instead of 2822? In fact,
> would it make more sense to reference RFC5321 instead of RFC5322?

You are right, that would make more sense. If no one objects, I will
make that change.

> 3) Section 3.1, mapping should only be done if the software knows for sure
> that the rules it is applying are correct for that domain. I suggest
> qualifying the last sentence so that it reads:
> 
>    Software implementing DNS lookup for the OPENPGPKEY RRtype MAY perform
> similar translation<del>s</del> rules while trying to find the OPENPGPKEY
> record if it has definitive knowledge of the rules applicable at the target
> domain.

I agree with the sentiment, although I'm not sure if "definitive
knowledge" about a "domain" is a fair thing to say, since there is not
RFC where an implementor could go and request such information about
how to get such knowledge of a certain domain. But I also have no better
alternative text suggestion right now. Anyone else?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2015 19:23:52 -0700

> add some text for this if I get a few more agreeing nods of people.

Maybe I've lost track of EAI, but from RFC 6530, I got the impression that all addresses already were in UTF-8. If so, you don't want to encourage people to double-encode.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 14 Mar 2015 03:25:50 -0000

>> the local-part on which to perform the SHA224 function.

Paul H is right.  Regular mail addresses are 7-bit ASCII, and EAI is
UTF-8.  Those are the only two choices, and since ASCII is a subset of
UTF-8, it's really only one choice.  See RFC 6530.

Section 3.1 seems very ill-advised -- it says the client probes for
various addresses which might be the person you want, but might
equally well be someone else if you guess wrong.  While it is unusual
for foobar@domain and FOOBAR@domain and foo.bar@domain to be different
people, that is and always has been entirely valid.  With + and -
variants, there's no consistency at all.  Nerds who are used to
sendmail think it's normal for foo+bar to be a variant of foo, but the
other 98% of the world doesn't.  And some even use foo-bar as a
variant of foo.

My advice would be to remove all of the current text in 3.1 and
replace it with a note that systems that publish records at names that
are hashed mailboxes may publish CNAMEs for variant mailbox hashes
that they consider to be equivalent.  That's safe, since the party
publishing the variants is the one that knows what they mean.  It's
also fairly hopeless once you get beyond folding stuff to lower case
and stripping dots since the number of possibilities explodes.

R's,
John

PS: If we have name variant rules, which I'm not at all sure we
should, they really should be the same for OPENPGPKEY and SMIMEA and
anything else that uses a hashed mailbox.  This suggests if we go down
that road, the name management belongs in a separate document from the
definition of the RR type, and it needs attention from the SMTP crowd.

---

From: Wil Tan <[email-masked]>
Date: Sat, 14 Mar 2015 15:08:12 +1100

On Sat, Mar 14, 2015 at 1:23 PM, Paul Hoffman <[email-masked]> wrote:

> Maybe I've lost track of EAI, but from RFC 6530, I got the impression that
> all addresses already were in UTF-8. If so, you don't want to encourage
> people to double-encode.

True, double encoding would be bad. However, from a practical perspective
it is likely that software would be working with addresses in a
Unicode-aware type that is native to the programming language, rather than
a byte string.

As such, I think it would be good if we could include text that specifies
the encoding without misleading implementers into double encoding. I
suggest breaking the first bullet in Section 3 into the following:

o The user name (the "left-hand side" of the email address, called the
"local-part" in the mail message format definition [RFC2822] and the "local
part" in the specification for internationalized email [RFC6530]) is
extracted from the email address. This does not include the at symbol ("@")
that separates the left and right sides of the email address.

o The user name SHOULD be converted to UTF-8, unless it is already encoded
in UTF-8.

o The user name should then be hashed using the SHA2-224 [RFC5754]
algorithm, with the hash being represented in its hexadecimal
representation, to become the left-most label in the prepared domain name.

.wil

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 Mar 2015 07:38:41 +0000

> add some text for this if I get a few more agreeing nods of people.

EAI email *addresses* ARE UTF-8 by definition.  There is simply no
mechanism to signal any other encoding, either in SMTP envelopes
or in primary message headers (where one can signal the encoding
of "phrases" like the display name, but not the address itself.

But if this is not obvious to everyone, it may be helpful to say so.

> You are right, that would make more sense. If no one objects, I will

I object.  You're not discussing SMTP, you're discussing email.  Email
addresses are defined in RFC 822/2822/5322 (5322 Section 3.4.1 addr-spec).

	http://tools.ietf.org/html/rfc5322#section-3.4.1

Any particular transport (SMTP say) representation of email addresses
seems to me to be the wrong object to describe here.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Mar 2015 09:01:07 -0700

On Mar 13, 2015, at 9:08 PM, Wil Tan <[email-masked]> wrote:
> o The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC2822] and the "local part" in the specification for internationalized email [RFC6530]) is extracted from the email address. This does not include the at symbol ("@") that separates the left and right sides of the email address.
> 
> o The user name SHOULD be converted to UTF-8, unless it is already encoded in UTF-8.
> 
> o The user name should then be hashed using the SHA2-224 [RFC5754] algorithm, with the hash being represented in its hexadecimal representation, to become the left-most label in the prepared domain name.

That seems pretty clear. Thanks!

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Mar 2015 15:05:09 -0400 (EDT)

> But if this is not obvious to everyone, it may be helpful to say so.

Yes, that surely deserves to be stated more clearly in the draft.

> seems to me to be the wrong object to describe here.

Point taken here as well. Thanks Viktor!

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Mar 2015 15:07:59 -0400 (EDT)

> and stripping dots since the number of possibilities explodes.

That sounds fine. Are you saying you prefer the document to not list the
example mappings we know about, or are you okay with still mentioning
the example mappings?

> definition of the RR type, and it needs attention from the SMTP crowd.

Agreed.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Mar 2015 15:08:58 -0400 (EDT)

> Maybe I've lost track of EAI, but from RFC 6530, I got the impression that all addresses already were in UTF-8. If so, you don't want to encourage people to double-encode.

I'll clarify that in the new text and run it by you so you can add the
same to the smimecert document.

Thanks,

Paul

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2015 15:06:54 -0400

> example mappings we know about, or are you okay with still mentioning

This whole can of worms needs attention from the people who think about 
mail all the time.  The RFCs are quite clear that mailbox namees are 
opaque and clients are not allowed to make any assumptions that similar 
names are the same mailbox.  Servers can use CNAMEs to publish likely 
variants that people will try, but I'm wondering whether it will still 
turn out to be too frustrating to use.

>> definition of the RR type, and it needs attention from the SMTP crowd.

OK.  Want me to split it out and do a draft?  Can't submit it now but we 
can talk about it in Dallas.

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, 15 Mar 2015 17:52:59 -0400 (EDT)

On Sun, 15 Mar 2015, John R Levine wrote:

> This whole can of worms needs attention from the people who think about mail 
> all the time.  The RFCs are quite clear that mailbox namees are opaque and 
> clients are not allowed to make any assumptions that similar names are the 
> same mailbox.  Servers can use CNAMEs to publish likely variants that people 
> will try, but I'm wondering whether it will still turn out to be too 
> frustrating to use.

That did not answer my question though. Do you prefer the example
mappings to be in the document or not? If a new document is started on
the issue of email address mappings, it should not stall progress on
this document. So I'm looking at text that points out the issue, yet
punts a solution elsewhere. I am thinking the current Section 3.1 with
only the last sentence changed could do that and this document can move
forward.

> OK.  Want me to split it out and do a draft?  Can't submit it now but we can 
> talk about it in Dallas.

I think a clarification on the case sensitivity issue and the well known
mappings would be a useful document and I'm willing to co-author.

Personally, I would like to see some advise telling email clients not to
auto-capitalize the first letter in an email address input box for
example. (hint to Apple for iOS)

I don't think we could advise anyone on interpreting ".", "-" or "+"
other that text proposed by Wil along the lines of "Only support these
mappings when you _know_ the target domain performs these". Which is
what the last line in Section 3.1 should say as well.

Paul

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2015 19:28:04 -0400

> mappings to be in the document or not?

As I think I said, the entire section 3.1 needs to go.  That includes the 
examples.

> example. (hint to Apple for iOS)

Only if you never want your draft to be published.  Please review previous 
correspondence for why.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Sun, 15 Mar 2015 19:36:49 -0400 (EDT)

> As I think I said, the entire section 3.1 needs to go.  That includes the 

What's the logic behind not mentioning a possible known problem for
implementors of OPENPGPKEY?

Paul

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2015 19:52:54 -0400

> implementors of OPENPGPKEY?

Because we have no workable solutions for it.  Probing addresses is a 
non-starter, servers publishing variants doesn't scale.

As I've said before, the reality that mail systems do fuzzy matching on 
incoming addresses, but not in a way that is at all consistent, is a big 
problem.  I don't think it makes sense to try to advance OPENPGPKEY or 
SMIMEA or _mailbox until we and the people who know about mail figure out 
what to do about it.  I'm asking them to take a look.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Sun, 15 Mar 2015 20:00:30 -0400 (EDT)

On Sun, 15 Mar 2015, John R Levine wrote:

> Because we have no workable solutions for it.

I do not find that an acceptable reason to not mention a known problem
in the document. It is clearly something implementors need to be aware
of.

> problem.

It is such a big problem that we should not even mention it in the document?

> I don't think it makes sense to try to advance OPENPGPKEY or SMIMEA 
> or _mailbox until we and the people who know about mail figure out what to do 
> about it.  I'm asking them to take a look.

This is a 20 year old problem. I see no reason why that 20 year old
problem needs to stop the advancements of the OPENPGPKEY or SMIMEA
RRtypes.

It would be great if these people would want to help with a replacement
text for Section 3.1.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 15 Mar 2015 20:00:30 -0400 (EDT)

Paul

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 15 Mar 2015 17:09:43 -0700

On Mar 15, 2015, at 4:52 PM, John R Levine <[email-masked]> wrote:

> As I've said before, the reality that mail systems do fuzzy matching on incoming addresses, but not in a way that is at all consistent, is a big problem.  I don't think it makes sense to try to advance OPENPGPKEY or SMIMEA or _mailbox until we and the people who know about mail figure out what to do about it.  I'm asking them to take a look.

Fuzzy matching on "mailboxes" bites in several places, far beyond email.  While way out of scope of everything being discussed here, I think the idea of having a cut point handoff from the domain certification, to the 'user' certification, is something we can't ignore.

Sendmail's plus-addressing scheme is a deployed example of that sort of usage.  Given [email-masked], we have all the bits to validate the RHS of the @, and the initial token of the LHS.  But with IoT smacking us in the face, sub-personal locators are very quickly going to become a fact of life.  How to deal with the bits starting at the '+' is scary.  And out of context here.  But it can't be ignored.

--lyndon

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2015 20:57:50 -0400

> Fuzzy matching on "mailboxes" bites in several places, far beyond email.  While way out of scope of everything being discussed here, I think the idea of having a cut point handoff from the domain c…

Right.  As I said before, it's a big can of worms.  If we think it needs 
to be addressed at all, we need to pull it out of the current drafts (such 
as section 3 of the openpgp draft) and deal with it directly.

> Sendmail's plus-addressing scheme is a deployed example of that sort of 
> usage.

There's a huge list of them, case folding, ignoring some dots, ignoring 
all dots, various sorts of LDAP things to match john.smith, johnsmith, 
jsmith, and j.smith, often data dependent so jsmith only works if it only 
matches on e address.

Regards,

---

From: James Cloos <[email-masked]>
Date: Mon, 16 Mar 2015 11:18:30 -0400

JL>> As I've said before, the reality that mail systems do fuzzy
JL>> matching on incoming addresses, but not in a way that is at
JL>> all consistent, is a big problem.

PW> It is such a big problem that we should not even mention it in
PW> the document?

I have to agree with Paul on this issue; Section 3.1 does not hurt
the draft and should not prevent its publication as an RFC.

I'm not as certain whether the language is ideal, and a separate
followup document further discussing the issue is not a bad idea.

But there is nothing wrong with this document noting the issue's
existance.

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

---

From: "John Levine" <[email-masked]>
Date: 17 Mar 2015 02:04:48 -0000

>PW> It is such a big problem that we should not even mention it in

Yes, it is.  You have no idea.

The stuff in section 3 of the openpgpkey draft is trying to
canonicalize mailbox names, i.e., given some mailbox name, find the
"real" mailbox name that it corresponds to.  This is an extremely
difficult problem that people have been scratching their heads about
literally for decades with no success.  With the advent of EAI,
mailboxes can be arbitrary UTF-8 rather than ASCII, which makes the
already intractable problem of what's equivalent to what much harder.
For example, folding upper and lower case in ASCII is easy, while in
EAI it pretty much impossible for a variety of reasons.  One new
problem (not the hardest) is that the case folding rules are language
specific -- the way you fold accented characters in Turkish is
different from the way you do it in French, and it's even different
between European French and Canadian French.  You cannot tell by
looking at a mailbox name what language it is.

Unless you are vastly smarter than everyone else who has looked at
this problem, you're not going to solve it any time soon.  Every
approach suggested so far is something we're aware of and is known not
to work when applied to the complex mess that is Internet e-mail.  If
you want to use hashes to represent mailbox names, you either have to
completely punt on variant names, which the users will hate, or stop
here, talk to people who understand the subtle reality of mail and see
if there's any way to come up with something that works.

As I've said before, if you try to advance a draft with language
anything like what's in section 3.1, it will be shot down in IETF last
call and again in the IESG, neither time by me.

I realize this isn't what you want to hear, but you've dived into a
swamp.  You may not recognize it as a swamp, but trust me, that's
where you are.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Mar 2015 22:17:37 -0400 (EDT)

>> PW> It is such a big problem that we should not even mention it in

Note how I wrote "mention", not "solve".

> Yes, it is.  You have no idea.

You say I cannot "mention" it.

> this problem, you're not going to solve it any time soon.

I am not trying to "solve" it. I just want to "mention" it.

> call and again in the IESG, neither time by me.

Which is why I asked you if the text just "mentioning" the problem
is okay or not. If this problem is such a taboo that we cannot even
mention it, it is the IETF process that needs fixing, not Section 3.1.

That said, since you seem to be in the know about what text leads to
failure, it would be good to know what text you think is least likely
to lead to failure (without saying "none" which is not an acceptable
choice to me and others)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Mar 2015 10:08:36 -0700

On Mar 15, 2015, at 5:57 PM, John R Levine <[email-masked]> wrote:
> Right.  As I said before, it's a big can of worms.  If we think it needs to be addressed at all, we need to pull it out of the current drafts (such as section 3 of the openpgp draft) and deal with it directly.
> 
>> Sendmail's plus-addressing scheme is a deployed example of that sort of usage.
> 
> There's a huge list of them, case folding, ignoring some dots, ignoring all dots, various sorts of LDAP things to match john.smith, johnsmith, jsmith, and j.smith, often data dependent so jsmith only works if it only matches on e address.

Historically, "the draft pretends the problem doesn't exist" causes ugly late surprises in the IESG, and then (often?) more convoluted RFCs. Having said that, John has a good point that the current wording sounds like it says "here are a few problems, and here is a potential solution".

Section 3.1 would be better worded as:

3.1.  Email address variants

Some email service providers and email software perform automatic mappings of the LHS of email addresses based on special characters.  This makes finding OPENPGPKEY record for a particular name that might be mapped impossible because there is no complete set of mappings and, worse, some common mappings conflict with each other.

It might be tempting for software that implements DNS lookup for the OPENPGPKEY RRtype to try to perform similar mappings while trying to find a particular OPENPGPKEY record. This SHOULD NOT be done because some mapping attempts might retrieve the key for the wrong user, depending on the mapping rules of the service provider or software platform.

--Paul Hoffman

---

From: Patrick Ben Koetter <[email-masked]>
Date: Tue, 17 Mar 2015 20:49:30 +0100

> It might be tempting for software that implements DNS lookup for the OPENPGPKEY RRtype to try to perform similar mappings while trying to find a particular OPENPGPKEY record. This SHOULD NOT be don…

+1

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: Brian Dickson <[email-masked]>
Date: Tue, 17 Mar 2015 15:26:16 -0700

On Mon, Mar 16, 2015 at 7:04 PM, John Levine <[email-masked]> wrote:

> "real" mailbox name that it corresponds to.
>

I think this can be summarized as a "publication vs discovery" problem.

Keys get published in DNS at specific locations, corresponding to hashes of
usernames. That is publication.

The username-equivalence problem is a discovery problem.

My suggestion is, standardize a PLACE (label) at which the email crowd can
iteratively codify their equivalence rules.

This puts the onus on them (the email folks), and gives them all the
control they need.

Publishing the applicable "rules" at a well-known location under a parent
domain, facilitates discovery, without needing to implement anything within
DNS.

The specifics (what to codify and how to implement) are things the
publishers (email providers and smtp providers) and the consumers (email
clients) can work out, on their own and without involving the DNS folks.
There is no specific need to uniqueness among the rules, even -- the same
mapping could have more than one name/code-point, even if it is
sub-optimal. E.g. different ISO-whatever country codes, might utilize the
same mappings, and those mappings might also be shared by regional entities
(like Quebec, or New Brunswick, in Canada). There may be a desire to have
"vanity" names for the same mappings, e.g. GOOGLE and YAHOO. There may be
related groups of rule sets, like GOOGLE_FR, GOOGLE_DE, where combinations
of simple mappings are applied (lowercase, remove dots, trim +, and then
apply language-specific mappings).

We don't need (or want, IMHO) to develop those encodings, merely
incorporate them by reference.
(The email folks can fight those battles.)

As an example, consider a new RRTYPE, of priority and rule, published at
_mboxrule.

_mboxcanon.example.com  IN MBOXRULE 1 LC_ASCII
_mboxcanon.example.com  IN MBOXRULE 2 FR_CA_NOACCENT

_mboxcanon.example.net  IN MBOXRULE 1 NO_DOTS
_mboxcanon.example.net  IN MBOXRULE 2 NO_PLUS_SUFFIX

8 bits of priority, and 16 bits of enumerated rules (from an IANA table),
is likely sufficient as a first cut, unless anyone has a better idea.
(Suggestion: reserve some code points for experimental, and some for local
use, however those might get implemented.)

If a given domain has "fuzzy" stuff, then they still have the ABILITY to
publish the same (user) keys at multiple hashed owner locations (equivalent
usernames, e.g. firstname.lastname and 8-letter-username), for the
enumerated variants.

It does not need to be the case that the entire problem space be solved
(all possible mailbox mappings). The ability to standardize and apply
"sane" (well-defined, simple, context-free and content-agnostic) rules,
might encourage adoption of such rules, and facilitate a sufficiently-high
level of interop, as to justify deployment of these rules, and OPENPGPKEY &
SMIME generally.

> One new

No, but if there is a well-known location that lists the applicable rules,
you _can_ tell what those rules are, just by looking at that well-known
(domain-wide) rule.

The specifics of _what_ each rule is, and who is "authoritative" for a
given rule, are thankfully out of scope for dnsop.

> if there's any way to come up with something that works.

I am suggesting we do both - punt on solving it, and providing just enough
rope to the email community.

_THE_ main thing is to recognize that there can be many case-folding rules,
and that it does not need to be unified.

At best, providing ways to publish the applicable set(s) of rules, and
maybe a way to prioritize their use in case of conflicting elements within
the rules, should be sufficient.

I strongly suggest that those rules get published by the email folks, as an
IANA registry or set of registries (well-known and local).

> swamp.  You may not recognize it as a swamp, but trust me, that's

No, we are standing at the edge of the swamp, admiring the guts of those
fighting the alligators.

Brian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Mar 2015 16:47:43 -0700

On Mar 17, 2015, at 3:26 PM, Brian Dickson <[email-masked]> wrote:
> My suggestion is, standardize a PLACE (label) at which the email crowd can iteratively codify their equivalence rules.

This is a suggestion to APPSAWG, not DANE. The email crowd has this problem (literally) decades before DANE was born. If the email crowd devises such a place, DANE can use it in the same way that regular email uses it.

--Paul Hoffman

(Disclaimer: I was director of the Internet Mail Consortium from 1996 to 2002)

---

From: "John Levine" <[email-masked]>
Date: 18 Mar 2015 00:13:00 -0000

>Some email service providers and email software perform automatic mappings of the LHS of
>email addresses based on special characters.  This makes finding OPENPGPKEY record for a
>particular name that might be mapped impossible because there is no complete set of
>mappings and, worse, some common mappings conflict with each other.
>
>It might be tempting for software that implements DNS lookup for the OPENPGPKEY RRtype to
>try to perform similar mappings while trying to find a particular OPENPGPKEY record. This
>SHOULD NOT be done because some mapping attempts might retrieve the key for the wrong
>user, depending on the mapping rules of the service provider or software platform.

Looks fine.  Here's some minor editorial suggestions:

I'd suggest taking out "based on special characters", since the most
common mapping is case folding.  The standard term for the LHS is
local-part, so you might as well use that and reference RFC 5321, sec
2.3.11 where it's defined.

Also, the SHOULD NOT would better be MUST NOT, to be consistent with
RFC 5321 which says "the local-part MUST be interpreted and assigned
semantics only by the host specified in the domain part of the
address."

(If you have a private agreement with someone and you have knowledge
of their internal mappings, you can do whatever you want, but of
course private agreements are outside the scope of standards.)

Having said all that, how useful do people think this will be if it
doesn't allow the local-part fuzz that mail systems provide?  If the
addresses to be looked up are picked mechanically from incoming mail
headers, it'd likely work fine.  If typed in from business cards, it
could be pretty frustrating.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Mar 2015 10:47:38 -0400 (EDT)

> course private agreements are outside the scope of standards.)

With this, we've gone a full circle. It feels strange to me to write a
MUST NOT, knowing that implementors will need to do this in practise.

But I guess I could live with it if the consensus moves this way, but to
me that seems only because I know the MUST NOT will be violated.

> could be pretty frustrating.

Or even typed in on an iphone for which you have an existing contact
with a lower case name, and it stupidly Uppercases it anyway when you
type.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Mar 2015 08:06:04 -0700

> me that seems only because I know the MUST NOT will be violated.

At first I bristled at John's proposed change, but he's right that RFC 5321 is completely clear on this topic, and it is a full standard. And, yes, lots of SMTP applications probably violate the MUST NOT as well, but that doesn't change it.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 18 Mar 2015 11:23:12 -0400

> At first I bristled at John's proposed change, but he's right that RFC 
> 5321 is completely clear on this topic, and it is a full standard. And, 
> yes, lots of SMTP applications probably violate the MUST NOT as well, 
> but that doesn't change it.

In my experience, people who write mail software understand the opaque 
mailbox rule, and try pretty hard to follow it.  Some cheat and do case 
folding to match Bob@domain to BOB@domain, but I can't think of any that 
match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA that 
actually knows what the addresses mean.

I can't emphasize strongly enough that any design that depends on people 
guessing addresses is fatally flawed.  If, as you're saying, this one 
does, it'll just be kicked back until it's redesigned to take out the 
need to guess.

Regards,

---

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Mar 2015 12:24:40 -0400

[ Random top post ]
So, it feels like we are approaching a compromise / consensus on this
bit (which is good, because this part was the bit we were least in
agreement on)

Let's give this a bit more time to settle, then I'm planning on a very
short  WGLC, restricted just to this question, and with a "We'll
assume you are OK with this, unless you say otherwise".

W

On Wed, Mar 18, 2015 at 10:47 AM, Paul Wouters <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Mar 2015 16:45:44 +0000

> assume you are OK with this, unless you say otherwise".

Was consensus reached on the _prefix for the sha224 hashes?  Distinct
for SMIMEA, OPENPGPKEY, ... or unified?

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Mar 2015 19:57:11 -0400

Ok, so there are still a number of outstanding things we need to
figure out on not just this draft, but the whole approach when it
comes to mail addresses.

 It seems that I may have been overoptimistic about the LHS of the
email address (and possibly the _prefix / DNAME solution), and if we
can just hand-wave this away...

Olafur and I will chat, but I think that we need some assistance from
Apps folk, and to have a proper discussion of this in the F2F
meeting...

Apologies to all for yanking you around. on the plus side, the network
in Dallas is starting tom come together nicely...

W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Mar 2015 18:24:58 -0500

Ok, so we are asking Paul to submit the updated draft once the window
opens, so that we have a clear slate.
We are also planning on having a discussion at the face to face
meeting on how we will deal with the LHS of email addresses in DANE.
The outcome of this discussion may / will influence the contents of
this, and possibly other documents. We need a single, clean way to
deal with finding <things> associated with an email address, not one
per document...

W

---

From: Petr Spacek <[email-masked]>
Date: Fri, 20 Mar 2015 15:39:27 +0100

> bit (which is good, because this part was the bit we were least in

Warren and list, I believe that the RDATA format is still underspecified which
seems like a major problem to me: Please see
http://www.ietf.org/mail-archive/web/dane/current/msg07390.html

Petr Spacek  @  Red Hat

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Mar 2015 19:28:16 +0000

> http://www.ietf.org/mail-archive/web/dane/current/msg07390.html

Thanks for the reminder.  I think we should at least explore the
question of what exactly does go into the RRDATA.  What parts of
a PGP public key should publishers include or exclude?  Will stating
a more precise definition improve interoperability?  

Should the interchange form for such "out of band" PGP public keys
be defined in some other document.  I've seen messages to the
effect that there's some interest in re-chartering the PGP working
group...

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 20 Mar 2015 17:49:47 -0400 (EDT)

On Fri, 20 Mar 2015, Viktor Dukhovni wrote:

> question of what exactly does go into the RRDATA.

IMHO, we already state that clearly in the latest text proposed to
this list, referencing the exact section of the openpgp RFC. The
latest proposed text was:

     The RDATA Presentation Format, as visible in textual zone files,
     consists of a single OpenPGP public key as defined in
     Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648]

> What parts of

Why should we decide any of this? As long as it is a valid openpgp
Public-Key Packet (Tag 6)

> be defined in some other document.

gpg and other tools have managed to do fine with openpgp public key
rings all over the place. In files, on key servers, via hpk or http.
The interchange format is called RFC 4880.

>  I've seen messages to the

All the more reason for us not to cherry-pick items of the public
key ring packet and leave it up to a new RFC updating 4880 to
reflect updates for modern openpgp use. By referencing RFC 4880,
we will get those updates by the new RFC that updates 4880.

Paul

---

From: Petr Spacek <[email-masked]>
Date: Tue, 24 Mar 2015 11:08:01 +0100

> Public-Key Packet (Tag 6)

I'm not convinced that RFC4880 section 5.5.1.1. clearly defines what clients
should expect.

The RFC 4880 section 5.5.1.1. in its entirety follows:
"""
5.5.1.1. Public-Key Packet (Tag 6)

   A Public-Key packet starts a series of packets that forms an OpenPGP
   key (sometimes called an OpenPGP certificate).
"""

> The interchange format is called RFC 4880.

That is an important but kind of invalid point:

Of course you can implement an interoperable OpenPGP implementation if you can
read what GnuPG does.

Still, I'm not convinced that RDATA format specification should be 'do what
GnuPG did back in 2015'.

Maybe I'm wrong and RFC 4880 defines exactly what packets client should expect
- in that case it would be nice to add a reference to particular section in
RFC 4880 so implementors have clear entry point and are not confused as I am.

> we will get those updates by the new RFC that updates 4880.

That is certainly an option if WG is okay with issuing RDATA format definition
which will be unclear at the time of issue.

-- 
Petr Spacek  @  Red Hat

---

From: Sean Leonard <[email-masked]>
Date: Wed, 25 Mar 2015 23:38:18 -0500

On Mar 18, 2015, at 10:23 AM, John R Levine <[email-masked]> wrote:

> In my experience, people who write mail software understand the opaque mailbox rule, and try pretty hard to follow it.  Some cheat and do case folding to match Bob@domain to BOB@domain, but I can't think of any that match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA that actually knows what the addresses mean.

Gmail does not recognize dots as distinguishable characters within usernames (mailboxes).

See
https://support.google.com/mail/answer/10313?hl=en

Therefore [email-masked], [email-masked], and [email-masked] are equivalent.

(It also does case folding.)

That would be a 500+ million mailbox software example...

Sean

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Mar 2015 04:53:52 +0000

> That would be a 500+ million mailbox software example...

That's for *their own* domain, the text you're replying to refers
to general address processing that would apply to other people's
domains (such as an MUA looking for keys might need to find the
keys for variant addresses).

So the questions are:

  * All other things being equal, would domain owners be better off
    serving the keys via DNS.

  * How important is the lack of support for variant addresses?
    Is it actually a problem if email to variant address forms
    (de-novo email, rather than replies to mail from the canonical
    form of the address) is sent in the clear for lack of (automatically
    discoverable) keys?

If the first answer is "yes" and the second is "no", then DNS is
a clear winner.  Otherwise, there are trade-offs to consider.

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 26 Mar 2015 08:31:12 -0500

> (It also does case folding.)

Right, and the canonical form is whatever you typed when you signed up, 
e.g., mine has one dot in the middle and no upper case.  This just 
confirms that you can't tell from the outside what an MTA does internally.

Regards,

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 26 Mar 2015 14:57:46 -0400

I guess I am confused as to why I would want to support either key
discovery or distribution for the (500million - 1) versions of my email
address that I don't use.

My mail agent only generates one version of my from address.   I only
convey one version in written, oral, and online forms of distribution.

I am perfectly happy if it is not possible to discover the 500million-1
variants of my email address that I don't use or exercise but that my mail
provider chooses to treat as equivalent.   Frankly if it was possible, I
would write mail filters to drop those variants on receipt, because they
clearly indicate some use of my email address that I did not endorse.

For my uses, straight hashing of the form of my address you are presented
with is all I want.  To be honest, I would consider it an undesirable
feature to support the versions of my address that I don't use.

Enabling the simple direct function of key retrieval for the addresses we
use, in a ubiquitous way would be very powerful.

We should leave for future study the issue of key retrieval for the
addresses we don't use.

dougm

On Thu, Mar 26, 2015 at 12:38 AM, Sean Leonard <[email-masked]> wrote:

> yes, lots of SMTP applications probably violate the MUST NOT as well, but
> that doesn't change it.
> >
> match bob+foo@domain or b.ob@domain to bob@domain, other than the MTA
> that actually knows what the addresses mean.
>
> Therefore [email-masked], [email-masked], and
> [email-masked] are equivalent.
>

-- 
DougM at Work

---

From: "John R Levine" <[email-masked]>
Date: 26 Mar 2015 14:02:39 -0500

> address that I don't use.

You may know exactly want versions of your address that you use, but in 
general, mail systems don't.  Google doesn't know whether you spell your 
address dougmwork or dougm.work or DougmWork or Dougm.work.  They might be 
able to guess based on the incoming mail they've seen, but as we've said 
over and over, guessing isn't on the table.

If you're suggested that every mail user will manually identify which 
versions of his or her mail address the mail provider should publish, that 
doesn't seem to scale very well.

Regards,

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 26 Mar 2015 15:20:17 -0400

That problem seems to be O(1).  As you noted, I did it once, when I created
the address.   My mail provider may choose to support all kinds of inbound
variants (UID@domain) that I don't even know about.

I transmit, document, and exchange exactly 1 version of my address.   I
would like to publish a key for [email-masked].   This seems to scale
quite well.

I consider it undesirable to publish keys for whatever variants my provider
chooses to support for their own reasons.  Tomorrow they might decide (for
their own reasons) to equate other transformations of the string.

I just don't understand the use case for thinking the key retrieval
function needs to support all such vendor specific transformations that I
don't use.

Google never has to figure out the problem you propose.  I set my from:
address.  I would like to publish a key for that.  Users trying to validate
my signed email will look up the from address I used.  If their user agent
sees [email-masked] and chooses to lookup [email-masked]
.... well, I am more than happy to have that validation fail.

dougm

-- 
DougM at Work

---

From: "John R Levine" <[email-masked]>
Date: 26 Mar 2015 14:30:03 -0500

> their own reasons) to equate other transformations of the string.

MTAs have been doing fuzzy matching on local-parts for over 30 years. 
It's a little late to tell them not to do it.

Regards,

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 26 Mar 2015 15:42:25 -0400

This seems to be a red herring to me.

I did not suggest that the MTA change its behavior at all.   How that issue
gets conflated with what I thought we were talking about is beyond me.
Maybe someone can explain.

I request that I be able to publish, and have others lookup the form of my
address that I use.

Given that the fuzzy matching rules are receiver specific, I find it hard
to believe that senders are somehow algorithmically generating variants of
my email.

But as I noted, if any exist that randomly transform the from address they
receive, I am fine with having validation fail.

I see this potential failure scenario to be miniscule, or at least smaller
than false positive errors by spam filters.

dougm

On Thu, Mar 26, 2015 at 3:30 PM, John R Levine <[email-masked]> wrote:

> MTAs have been doing fuzzy matching on local-parts for over 30 years. It's
> a little late to tell them not to do it.
>
>
> Regards,

-- 
DougM at Work

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Mar 2015 14:45:39 -0500

> would like to publish a key for [email-masked].   This seems to scale

You do.

Others use aliases for all sorts of reasons.  E.g., joe+dane (some
joe's address for posting to this list, say).

> their own reasons) to equate other transformations of the string.

If you were the sort who likes to use a different sender address
(typically an alias of your primary address) for each list, then you
would consider it desirable.

> .... well, I am more than happy to have that validation fail.

Google does too have to figure out how to canonicalize your aliases:
because they chose to apply a fuzzy matching rule of their own design.
Google did that because they could.

Nico
--

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 26 Mar 2015 15:57:56 -0400

For any set of aliases that are manually configured, publishing a key, or
CNAME for each of those is of the same order of complexity as establishing
the alias itself.

When I try to validate the sig for [email-masked] I will look that up.

Unless your user agent generates a fuzzy match variant of your from:
address outbound with each email, I am not sure that the scaling problem is.

I still fail to see what inbound fuzzy match of local parts has to do with
the problem.

dougm

-- 
DougM at Work

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Mar 2015 15:13:30 -0500

> When I try to validate the sig for [email-masked] I will look that up.

<name>+<list> is not configured.  They're magic... if your MTAs are
configured so anyways.  These uses exist precisely because they were
a) permitted, b) handy.  So now we have to deal with them.

> I still fail to see what inbound fuzzy match of local parts has to do with

It's true that we don't have to specify a lookup service to deal with
fuzzy matching.  However, the <name>+<list> users will have start
manually publishing those.  That seems like a pain.

Also, using DNS for this opens mail domains to zone walking to find
mailboxes, whereas a proper lookup service wouldn't (it would still be
an oracle, but there would be no NSEC* to facilitate discovery of all
email addresses at the domain).

Nico
--

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 26 Mar 2015 20:37:35 +0000

Hey Nico, 

> a) permitted, b) handy.  So now we have to deal with them.

Indeed, but I think this a powerful feature that lets users advertise their intent.  If someone wants to add protections to their list subscriptions, or wants to add different crypto to different email aliases, then configuring the encr/signing behavior independently is a feature, not a bug, me thinks.

> manually publishing those.  That seems like a pain.

Again, if someone wants to receive encrypted email or have their signatures verified, it seems reasonable to advertise their intentions explicitly.  I really think this is a feature, not a bug.

> email addresses at the domain).

I mentioned a candidate approach to dealing with this at the mic yesterday.  I think this could easily be a domain and MUA configurable option with some of the proposed enhancements we’ve coded into SMIMEA, but I don’t want to distract this thread too much.  Maybe we can start a new thread for that (over beer, perhaps). ;)

Eric

---

From: George Michaelson <[email-masked]>
Date: Thu, 26 Mar 2015 15:50:16 -0500

Mail systems are exposed to the entire header. The Envelope isn't
neccessarily the same as the header (this we know)

So absent a wilingness to add a magic third field to the Mail From: field
which would be [....hash of PGP] How about we have X- behiour explored in
the mail header, which is all safe for now and MUA exposed?

When we know how that works, we can move on what we really need, which is
envelope level:

MAIL FROM: "George is Nuts" <[email-masked]> PGP-KEY-HASH-HERE

-G

On Thu, Mar 26, 2015 at 3:37 PM, Osterweil, Eric <[email-masked]>
wrote:

> Indeed, but I think this a powerful feature that lets users advertise
> their intent.  If someone wants to add protections to their list
> subscriptions, or wants to add different crypto to different email aliases,
> then configuring the encr/signing behavior independently is a feature, not
> a bug, me thinks.
>
> Again, if someone wants to receive encrypted email or have their
> signatures verified, it seems reasonable to advertise their intentions
> explicitly.  I really think this is a feature, not a bug.
>
> I mentioned a candidate approach to dealing with this at the mic
> yesterday.  I think this could easily be a domain and MUA configurable
> option with some of the proposed enhancements we’ve coded into SMIMEA, but
> I don’t want to distract this thread too much.  Maybe we can start a new
> thread for that (over beer, perhaps). ;)
>
> Eric

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Mar 2015 15:53:00 -0500

> Indeed, but I think this a powerful feature that lets users advertise their intent.  If someone wants to add protections to their list subscriptions, or wants to add different crypto to different e…

People who do this mostly want to filter into folders based on
recipient address.  They are able to magically create new sender
addresses without doing anything special.

> Again, if someone wants to receive encrypted email or have their signatures verified, it seems reasonable to advertise their intentions explicitly.  I really think this is a feature, not a bug.

A lookup protocol does this, either by applying local rules such as
s/[+].*$// or whatever they like.

> I mentioned a candidate approach to dealing with this at the mic yesterday.  I think this could easily be a domain and MUA configurable option with some of the proposed enhancements we’ve coded int…

I don't remember it.  Can you remind us?  Debating the +list thing is
more distracting, I think :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Mar 2015 15:54:48 -0500

> MAIL FROM: "George is Nuts" <[email-masked]> PGP-KEY-HASH-HERE

What problem is this solving?

---

From: George Michaelson <[email-masked]>
Date: Thu, 26 Mar 2015 15:59:09 -0500

If you've never received mail from somebody before you cannot rely on any
aspect of lhs@rhs to inform their key. So the game is lost if anyone thinks
proscriptive logic around lhs@ is going to be abided by.

The discussion in the room was about interpretation of lhs@

I think the sensible path out is to get people to send mail, and include
PGP key in the envelope. Any recipient you see this for, you have their PGP
ID as a proffer and its associated with their email identity. Which builds
your set of recipients which have known PGP ID very quickly once you
confirm it out of band.

Likewise for lists. Your sender is exposed to the list mailer. Your PGP ID
is scraped from Envelope.

And, since Envelope is from MTA not MUA, it has some traction for being set
by local admin so the local admin LDAP can populate the outbound PGP ID
into the MAIL FROM

No .sigs required.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 27 Mar 2015 08:37:43 +0100

> email addresses at the domain).

How can you zone walk to find mailboxes when the localpart is hashed? Or did you propose a solution where the localpart is not hashed?

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 27 Mar 2015 08:37:52 +0100

On 26 mar 2015, at 19:57, Doug Montgomery <[email-masked]> wrote:

> I guess I am confused as to why I would want to support either key discovery or distribution for the (500million - 1) versions of my email address that I don't use.
> 
> My mail agent only generates one version of my from address.   I only convey one version in written, oral, and online forms of distribution.
> 
> I am perfectly happy if it is not possible to discover the 500million-1 variants of my email address that I don't use or exercise but that my mail provider chooses to treat as equivalent.   Frankly if it was possible, I would write mail filters to drop those variants on receipt, because they clearly indicate some use of my email address that I did not endorse.
> 
> For my uses, straight hashing of the form of my address you are presented with is all I want.  To be honest, I would consider it an undesirable feature to support the versions of my address that I don't use. 
> 
> Enabling the simple direct function of key retrieval for the addresses we use, in a ubiquitous way would be very powerful.  
> 
> We should leave for future study the issue of key retrieval for the addresses we don't use.

I'm completely agree with Doug here. MTAs may do all kinds of magic matching, what matters is what address the sender/receiver use and providing a solution for that is very powerful.

	jakob

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2015 18:46:11 -0000

>CNAME for each of those is of the same order of complexity as establishing

For over a decade, I've been doing the common trick of inventing a new
address each time I sign up for something.  Correct me if I'm wrong, but
you appear to be saying that now, I have to stop, go to some sort of DNS
provisioning system, tell it about the name I'm about to invent, publish
the new record, and wait for it to propagate before I can go back to the
web page where I'm about to use the name.

Also, I have no idea what all of the addresses are that I've made up
over the years, many of which still get mail from whoever I gave them
to.  It appears I'm out of luck there.

>address outbound with each email, I am not sure that the scaling problem is.

There are plenty of mail systems that do that.  Perhaps it would be
helpful to learn more about the way that modern mail systems work.

R's,
John

---

From: [email-masked]
Date: Sun, 29 Mar 2015 17:00:46 -0400 (EDT)

> to.  It appears I'm out of luck there.

For one, you can do *._openpgpkey.example.com. IN OPENPGPKEY [...]

Second you should really have the email address listed as ID on you
openpgp key entry anyway.

Third, you can keep doing this fine and not receive encrypred email,
just like you have been doing all of those years.

These are not the problems you are looking for,

Paul

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sun, 29 Mar 2015 21:12:14 +0000

+1

Eric

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2015 17:14:13 -0400

> For one, you can do *._openpgpkey.example.com. IN OPENPGPKEY [...]

My system has more than one user, so we have addresses like johnl-* 
bobf-*.  How are we supposed to handle that with DNS wildcards?

> openpgp key entry anyway.

I do, and thousands of subaddresses, too, and I'd like to let people send 
me mail just like they do now, only encrypted.

> just like you have been doing all of those years.

I'm not very interested in a "solution" that doesn't match the way e-mail 
works, and has worked for decades.  At the session in Dallas, it was 
pretty clear that the other people at the mike with extensive e-mail 
experience aren't either.

This is starting to remind me of too many other discussions of mail 
security hacks that don't match the way that mail actually works, in which 
the propnents argue that the parts of our working mail that don't happen 
to match the hack was broken all along.  (See, for example, endless 
arguments about "forgery" in SPF and DMARC lists.)

Regards,

---

From: [email-masked]
Date: Sun, 29 Mar 2015 17:28:27 -0400 (EDT)

On Sun, 29 Mar 2015, John R Levine wrote:

> I do, and thousands of subaddresses, too, and I'd like to let people send me 
> mail just like they do now, only encrypted.

This draft is about the use of openpgp and email. It is not a swiss-army
knife of email encryption. Note that I said "should have the email
address", and it is explictly not a requirement in the document, exactly
so you that do not need to add dozens of IDs if you do not want to.

> works, and has worked for decades.  At the session in Dallas, it was pretty 
> clear that the other people at the mike with extensive e-mail experience 
> aren't either.

You are confused about the document. This document is for:

    OpenPGP is a message format for email (and file) encryption, that
    lacks a standardized lookup mechanism to obtain OpenPGP public keys.
    This document specifies a method for securely publishing and locating
    OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource
    Record.

It does not have as goal to design a method for ubiquitous email
encryption for all possible uses of email and encryption technologies.

I am happy to see that the openpgpkey draft reinvigorated the email people
into looking at a solution for the generic email address to recipient
mapping. I will keep a close eye on the progress made by the APP area
and email experts. I'd be happy to write up a bis document to the
openpgpkey document once the APP area has a draft document out on this
issue.

Paul

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2015 17:36:15 -0400

> encryption for all possible uses of email and encryption technologies.

Nobody's asking for that, just for something that works for the way e-mail 
actually works, rather than what might as well be only for adddresses that 
start with the letters A through F.

> I am happy to see that the openpgpkey draft reinvigorated the email 
> people into looking at a solution for the generic email address to 
> recipient mapping.

I'll be sending one along shortly.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 30 Mar 2015 02:37:34 +0000

On Sun, Mar 29, 2015 at 05:36:15PM -0400, John R Levine wrote:

> >mapping.

If we're reconsidering the design, perhaps a smaller thing to
reconsider is the idea (IIRC my fault) to use SHA-224 in an attempt
to handle long (> 63 octet) local-parts, and avoid false matches
due to case folding.

An alternative is to go back to the original base32 encoding, which
is lossless, and thus can allow the remote DNS server (a special-purpose
DNS lookup engine serving a zone with per-user information) to
decode the local-part and perform whatever fuzzy matching may be
appropriate.

The lossless encoding can support longer names by breaking them up
into multiple labels.

This allows static DNS to be published where desired, and custom
code to produce dynamic results when appropriate.

-- 
	Viktor.

---

From: Doug Montgomery <[email-masked]>
Date: Mon, 30 Mar 2015 01:39:17 -0400

> to.  It appears I'm out of luck there.

I am not sure I understand the use case of wanting to enable opportunistic
inbound encryption to all of the thousands of address that you can't even
remember.  But OK, is your use case is that you want keying (the same
keying?) for all 500M potential variants? .... or just the thousands you
have used?

What about the person who might want different keying for his personal
email and that of his mailing lists (assuming that is what many folks do
with their aliases).

Actually there are strict compliance implications about managing network
identities in many commercial environments, where the idea that on is
creating keying material for other, non explicitly created identities,
won't fly.  So if you enable key discovery and retrieval the 500M variants,
please provide a mechanism to explicitly disable this feature too.

As for DNS provisioning, none of this is going anywhere if there isn't
significant automation between identity creation and keying.  The vast
majority of users don't even know there is a DNS.

Personally, I am interested in enterprise-class solutions.  Here if the
DANE keying material is not dynamically updated from our
identity/credential management system, it is a complete non-starter.

> helpful to learn more about the way that modern mail systems work.

I am aware of how mail modern systems work (many have better ways of
organizing email than generating thousands of addresses :).   I was
speaking of the hypothetical 500M algorithmic variants.  I assume your mail
system is not randomly generating your thousands of aliases.

I am also aware of the problem I thought we were trying to solve.  What I
heard at the mic was that solving the general problem of keying that
matches all the various local fuzzy matching rules of modern mail systems
was either intractable, or outside the scope of DANE, or both.  Let alone
taking on the problem of those who don't want that behavior, or might want
different keys on different local aliases.

What I heard after the meeting on the list was some support of solving the
simple problem in a ubiquitous way in DANE.   I am guessing we would
provide a solution that covers the vast majority of users with a simple one
key per unique LHS.

I think there may be support for solving the simple problem in DANE now.

As for the more complex scenarios, it might warrant revisiting the use
cases to understand the requirements, design trade offs of if, where and
how the issue is addressed.

-- 
DougM at Work

---

From: Alexis shaw <[email-masked]>
Date: Mon, 30 Mar 2015 17:55:51 +1100

Listening in why not allow the certificates to be defined on a regex, and have the queries to the database return a regex match. Seems to solve the problem. Email address grammars more complex than a regular expression seem a pain anyway. 

Regards
Alexis Shaw b

> On 30 Mar 2015, at 4:39 pm, Doug Montgomery <[email-masked]> wrote:
> 
> 
> 
> I am not sure I understand the use case of wanting to enable opportunistic inbound encryption to all of the thousands of address that you can't even remember.  But OK, is your use case is that you want keying (the same keying?) for all 500M potential variants? .... or just the thousands you have used?
> 
> What about the person who might want different keying for his personal email and that of his mailing lists (assuming that is what many folks do with their aliases).
> 
> Actually there are strict compliance implications about managing network identities in many commercial environments, where the idea that on is creating keying material for other, non explicitly created identities, won't fly.  So if you enable key discovery and retrieval the 500M variants, please provide a mechanism to explicitly disable this feature too. 
> 
> As for DNS provisioning, none of this is going anywhere if there isn't significant automation between identity creation and keying.  The vast majority of users don't even know there is a DNS.
> 
> Personally, I am interested in enterprise-class solutions.  Here if the DANE keying material is not dynamically updated from our identity/credential management system, it is a complete non-starter.
>  
>> 
> I am aware of how mail modern systems work (many have better ways of organizing email than generating thousands of addresses :).   I was speaking of the hypothetical 500M algorithmic variants.  I assume your mail system is not randomly generating your thousands of aliases.
> 
> I am also aware of the problem I thought we were trying to solve.  What I heard at the mic was that solving the general problem of keying that matches all the various local fuzzy matching rules of modern mail systems was either intractable, or outside the scope of DANE, or both.  Let alone taking on the problem of those who don't want that behavior, or might want different keys on different local aliases.
> 
> What I heard after the meeting on the list was some support of solving the simple problem in a ubiquitous way in DANE.   I am guessing we would provide a solution that covers the vast majority of users with a simple one key per unique LHS.
> 
> As for the more complex scenarios, it might warrant revisiting the use cases to understand the requirements, design trade offs of if, where and how the issue is addressed.
>  
>> 
>> R's,
>> John
> 
> 
> 
> -- 
> DougM at Work

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 11:57:27 -0500

> code to produce dynamic results when appropriate.

I like this.  A lookup protocol would be optional.  But I think we
need to specify the lookup protocol, and MUAs [that support DANE for
PGP/S/MIME] will need to support it.  The lookup protocol can only be
optional to provide; it can't be optional on the client-side.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 30 Mar 2015 17:21:34 +0000

> optional to provide; it can't be optional on the client-side.

My main concern with this direction is that ISP iterative resolvers
act as open proxies for this protocol, and:

  * Add latency because caching of lookup results is unlikely to scale. 

  * Suffer from bloated caches full of negative replies for billions
    of accounts.

  * Make it more difficult for the final servers to detect abusive
    clients that are doing dictionary (directory harvesting) attacks.
    [ Yes email addresses are not secrets, but some opacity can be
      useful. ]

If none of the above are compelling, then going back to a lossless
encoding may be a reasonable compromise.  Otherwise, we can take
the view that:

    * The multitude of addresses per user problem is not a problem,
      only a small specific number of addresses will support encryption
      (those may need to appear in the public key "certificates" anyway).

    * DNS is here and scales to high query volumes.

Or that:

    * It must be possible to E2E protect all the variant addresses,
      by returning the same keys for variants as for the canonical
      address.

    * Email operators will not want to publish user to key mappings
      in their current DNS, and no DNS front-end to their LDAP or
      similar directories is presently available.  Since new code
      is needed regardless, its protocol may as well be designed
      specifically for this problem.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 14:18:16 -0500

>   * Add latency because caching of lookup results is unlikely to scale. 

Requiring client support for the lookup protocol solves this.  Sites
with many mailboxes can implement the lookup protocol and not publish
mailbox names in the DNS.

>   * Suffer from bloated caches full of negative replies for billions

Ditto.

>     [ Yes email addresses are not secrets, but some opacity can be

Ditto.

> If none of the above are compelling, then going back to a lossless

I think they are quite compelling

> [...]

Don't we need DANE for e-mail signature signing key verification too?

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Mar 2015 15:28:33 -0400 (EDT)

>>   * Suffer from bloated caches full of negative replies for billions

Caches already need to have extensive policies for abuse queries and
when legitimatelly running out of resources and figuring out what to
flush. Let the DNS/cache implementors handle that - they've done a good
job so far. Similarly, trust the cache implementors to deal with many
_positive_ entries for large records.

>>     [ Yes email addresses are not secrets, but some opacity can be

That will just make the botnet slower and more distributed. Any
sufficiently busy domain won't really be able to slow down the botnet.
Think of gmail or yahoo, how much rate limiting can they afford without
locking out real clients?

> I think they are quite compelling

I don't think these are compelling at all.

I'm not sure how the lossless helps either, unless either the DNS server
does fuzzy record returning (which I cannot see work with DNSEC) or
you move the lookup protocol outside DNS. Either way, this document and
an implementation in DNS does not gain anything by using
base32/lossless.

> Don't we need DANE for e-mail signature signing key verification too?

Yes you can use it for that too, but I'm not sure how this relates to
the current discussion.

Paul

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2015 01:17:15 -0000

>code to produce dynamic results when appropriate.

I wrote up a draft summarizing the ways one might do mailbox
name lookups in the DNS with something close to the local-part
rules that MTAs have:

http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/

There's two reversible encodings, including a worked out version of
base32 that handles full 64 character local-parts, preserves the
lexical order of local-parts, and makes signed dynamic zones at least
somewhat possible, an implementation of regular expression matching
that I think is cool, but probably doesn't scale adequately for large
mail systems, and a straightforward way to securely identify a web
lookup service.

As far as I can tell, the base32 approach handles everything that
hashing does, is no harder to use if you want to publish a static set
of names, but still offers the possibility for large mail systems to
serve stuff on the fly.  Take a look.  I can send you a tiny python
script that turns local-parts into the base32 names if you want.

R's,
John