Re: [dane] Request DANE ALPS (another attempt to canonicalize local parts)

["John R Levine" <[e-mail]>]

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:
> On 3/7/2016 4:54 AM, John Levine wrote:
>> In article <[e-mail]> you write:
>>> 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.
>> 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.
>
> 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: *@ietf.taugh.com 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
>
>
>

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