Subject: [dane] Request DANE ALPS discussion time at IETF 95

From: Sean Leonard <[email-masked]>
Date: Sun, 6 Mar 2016 22:20:39 -0800

Hello:

As the chairs graciously requested and got a meeting slot in Buenos 
Aires, I would like to request DANE ALPS (Alternative Local-Part 
Synthesis) discussion time at IETF 95.

The Internet-Draft was posted back in October:
http://mailarchive.ietf.org/arch/msg/dane/5oV9mDolVS09UoF_ZCQOWAH1f9k

https://tools.ietf.org/html/draft-seantek-dane-alps-00

There has been discussion about local-part and e-mail address 
equivalence issues on other IETF mailing list(s) in the last couple of 
months. The Mail Gods say that only the receiving MTA gets to determine 
whether different local-parts are "equal". "Equal" means "deliver to the 
same mailbox" (a conceptual entity). They are right. The proposed ALPS 
protocol does not change anything about this. To the extent people 
perceive otherwise, it needs to be clarified and cleared up.

But the issue is an important one for storing names--particularly e-mail 
address-based names--in DANE, for S/MIME, PGP, and other future protocols.

I suppose that the presentation and discussion time should include not 
only ALPS, but a review of other approaches (see, e.g., John Levine's 
thread "Encoding local parts in better ways" and associated I-D). It 
should also review some of the most common local-part equivalence 
constructs, i.e.:
differences solely attributable to case
sub-addressing ( + - and = )
return-path randomization etc.
UTF-8 (beyond ASCII range)

Regards,

Sean

---

From: "John Levine" <[email-masked]>
Date: 7 Mar 2016 12:54:50 -0000

>Synthesis) discussion time at IETF 95.

This draft belongs in ietf-smtp or maybe appsarea, not DANE.  It's an
interesting idea, but since it changes the rules about who interprets
local-parts, it's an update to RFC 5321.

Also, it's an issue that affects people in a lot of places other than DANE.
Pkix has been having somewhat similar discussions about the names in X.509
certificates.

R's,
John

---

From: Sean Leonard <[email-masked]>
Date: Mon, 7 Mar 2016 22:16:06 -0800

> Pkix has been having somewhat similar discussions about the names in X.509

As the document itself states (repeatedly), the DANE ALPS proposal is 
very specific to DANE. It does not affect how the mail infrastructure 
interprets local-parts, because to do otherwise would anger the Mail 
Gods. We are leaving the issue alone. Local-Part is and remains left to 
the interpretation of the receiving MTA.

The point of DANE ALPS is to reduce the burden of maintaining a 
bajillion variations of records, for operating a DANE/DNSSEC-enabled 
zone. Consider a case where the owners want *all* messages sent to 
e-mail addresses in a domain to use the same key. Perhaps that key is a 
master encryption key for policy reasons, that will be decrypted by some 
gateway. Another case is where one user maintains the whole domain: 
[email-masked] e-mail addresses should all be encrypted to the same 
key and read (ultimately) by the same user, even if the messages get 
fanned out into different mailboxes on the back end. In such cases, is 
it desirable for the DANE/DNSSEC-enabled zone to maintain a bajillion 
different records with the same key info, or just to maintain one 
record, and have a mechanism to point queries to that specific record? 
The latter is simply more efficient (and more easily auditable).

Now, a possible outcome of the WG presentation/meeting is that the 
proposal has broader application than just DANE. In that case, expanding 
or moving it elsewhere would be fine. But we need to have that discussion.

Yes, it came up in PKIX recently...there is a broader question about how 
to determine e-mail address equivalence, when the two inputs are not 
bit-for-bit identical. This is an industry-wide problem. However, the 
DANE ALPS solution is about alternate queries of the DNS zone between a 
DNS client and a DNS server, not equivalence. It is specific to the way 
that DANE operates and is not intended to be a published general 
statement about how the domain's MTA fans out mail.

draft-osterweil-dmarc-dane-names also tries to address the matter using 
DMARC records. However, it goes a step further by saying 
"canonicalization policy"--which implies that it is promulgating 
interpretations of the local-part that might cause a disturbance in the 
(Mail Gods') Force. See:
http://mailarchive.ietf.org/arch/msg/dane/gWhYXtSyNGh2D2uuDp99LWHzBSU

That approach should also be covered and discussed.

So now we have at least four different approaches: a) do nothing, b) 
draft-seantek-dane-alps, c) draft-levine-dns-mailbox (a collection of 
different approaches), d) draft-osterweil-dmarc-dane-names. Obviously 
the WG is struggling to do something here, hence, discussion.

Regards,

Sean

---

From: "John R Levine" <[email-masked]>
Date: 8 Mar 2016 09:32:05 +0100

I think it's fair to say that doing an end run around the "Mail Gods" with 
yet another attempt to canonicalize local parts will not make them any 
less annoyed.  Hand waving claims that it's doing something else doesn't 
make it so.

I hope it's obvious why one approach to doing it in DANE and a different 
incompatble approach in PKIX would be a bad idea.

R's,
John

On Mon, 7 Mar 2016, Sean Leonard wrote:
> As the document itself states (repeatedly), the DANE ALPS proposal is very 
> specific to DANE. It does not affect how the mail infrastructure interprets 
> local-parts, because to do otherwise would anger the Mail Gods. We are 
> leaving the issue alone. Local-Part is and remains left to the interpretation 
> of the receiving MTA.
>
> The point of DANE ALPS is to reduce the burden of maintaining a bajillion 
> variations of records, for operating a DANE/DNSSEC-enabled zone. Consider a 
> case where the owners want *all* messages sent to e-mail addresses in a 
> domain to use the same key. Perhaps that key is a master encryption key for 
> policy reasons, that will be decrypted by some gateway. Another case is where 
> one user maintains the whole domain: [email-masked] e-mail addresses should 
> all be encrypted to the same key and read (ultimately) by the same user, even 
> if the messages get fanned out into different mailboxes on the back end. In 
> such cases, is it desirable for the DANE/DNSSEC-enabled zone to maintain a 
> bajillion different records with the same key info, or just to maintain one 
> record, and have a mechanism to point queries to that specific record? The 
> latter is simply more efficient (and more easily auditable).
>
> Now, a possible outcome of the WG presentation/meeting is that the proposal 
> has broader application than just DANE. In that case, expanding or moving it 
> elsewhere would be fine. But we need to have that discussion.
>
> Yes, it came up in PKIX recently...there is a broader question about how to 
> determine e-mail address equivalence, when the two inputs are not bit-for-bit 
> identical. This is an industry-wide problem. However, the DANE ALPS solution 
> is about alternate queries of the DNS zone between a DNS client and a DNS 
> server, not equivalence. It is specific to the way that DANE operates and is 
> not intended to be a published general statement about how the domain's MTA 
> fans out mail.
>
> draft-osterweil-dmarc-dane-names also tries to address the matter using DMARC 
> records. However, it goes a step further by saying "canonicalization 
> policy"--which implies that it is promulgating interpretations of the 
> local-part that might cause a disturbance in the (Mail Gods') Force. See:
> different approaches), d) draft-osterweil-dmarc-dane-names. Obviously the WG 
> is struggling to do something here, hence, discussion.
>
> Regards,
>
> Sean
>
>
>

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

---

From: "Olafur Gudmundsson" <[email-masked]>
Date: Tue, 8 Mar 2016 06:30:02 -0500 (EST)

Sean,
<chair-hat> 
Thank you for your submission of this draft. 
The chairs have reviewed this, and we think it is an interesting contribution to the IETF email normalization discussion. 
BUT while this may help OPENPGP and SMIMA limit the "search" for their record lookups, it is not strictly needed. 
In your draft there is nothing that is strictly security related, thus it does not fit within our charter, additionally it is outside the expertise of most of its participants. 
We strongly recommend that you take this work to the APPSAREA where there are more of "The Mail Gods" for discussing this issue. 
We will not be using this document as justification to meet. If we *do* meet, and there happens to be free time, we may be able to give you some time to discuss it, but simply an an "FYI", not something which DANE might adopt / really discuss
Olafur & Warren
 
On Monday, 7 March, 2016 01:20, "Sean Leonard" <[email-masked]> said:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Sean Leonard <[email-masked]>
Date: Tue, 8 Mar 2016 20:28:38 -0800

Okay. Thanks and I respect the decision of the chairs.

(Actually it doesn't actually "limit" the search...it's more like it 
casts a broader net. But anyway.) Since we are moving on and such, there 
is one issue about the local-part that affects 
draft-ietf-dane-openpgpkey and draft-ietf-dane-smime, related to proper 
(un)escaping, which I will comment on in a separate thread.

Sean

On 3/8/2016 3:30 AM, Olafur Gudmundsson wrote:
> The chairs have reviewed this, and we think it is an interesting 
> contribution to the IETF email normalization discussion.
> BUT while this may help OPENPGP and SMIMA limit the "search" for their 
> record lookups, it is not strictly needed.
> In your draft there is nothing that is strictly security related, thus 
> it does not fit within our charter, additionally it is outside the 
> expertise of most of its participants.
> We strongly recommend that you take this work to the APPSAREA where 
> there are more of "The Mail Gods" for discussing this issue.
> We will not be using this document as justification to meet. If we 
> *do* meet, and there happens to be free time, we may be able to give 
> you some time to discuss it, but simply an an "FYI", not something 
> which DANE might adopt / really discuss
> Olafur & Warren
>