Hi WG, This whole local-part problem (aliases, folding and authority) has been nagging in the back of my head the last couple of days. And I realized this might be an issue that shouldn't be solved on the DNS-side of things.
Even though the DNS is a very nice, sturdy and fast protcol, I feel it is not flexible (enough) for the things we are trying to do with it. We've not reached the limit of the protocol, but what we're trying to do feels like a hack. The local part issues we're running into are essentially part of a larger discovery problem that should not be solved in the DNS. Now, the IETF has standardized a mechanism to do discovery like this in the form of webfinger, RFC7033[1]. This would allow an MTA/MUA to lookup the full recipient address (in the format given by the end user) at the webfinger server of that domain. This server could do the casefolding/aliasing using the defined 'aliases' field in the response body. This allows also for easy expansion of e.g. the [email protected] addresses, as webfinger can return the canonical address ([email protected] in this case) as the 'subject' in the response body (see section 4.4.1 of RFC7033). Webfinger also allows 'properties' to be set in the response body, allowing it to send the public key in the response. Webfinger is standardized to use HTTPS only, we could further strengthen this by requiring a TLSA record for the host the MTA/MUA is connection to. Using Webfinger has several advantages and disadvantages, off the top of my head: Advantages: - No hashing involved - Usage of existing technology (and providing a use-case for it) - Administration of both SMIMEA and OPENPGPKEY information can still be done by different entities within an organisation - No weird shoe-horning things into DNS - Casefolding can be resolved by the receiving end in a dynamic fashion Disadvantages: - MTAs will need to talk HTTPS - It's not DANE (more like 'DNS-Assisted') - It kind-of defeats the purpose of this WG - No NSEC3-like protection from address leakage (see sections 9.2 and 9.3 of RFC7033) I assume there'll be a lot of comments on this, what are your ideas about this? Best regards, Pieter Lexis 1 - https://tools.ietf.org/html/rfc7033 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
