On 3/7/2016 4:54 AM, John Levine wrote:
In article <[email protected]> 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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
