On Wed, Feb 25, 2015 at 12:50:59PM -0500, Paul Wouters wrote:
> >Viktor, would you mind writing up the proposal again (in a new thread)
> >and we'll call consensus on this approach?
>
> I think I explained this before, but I don't like anything that requires
> putting more than one entry into the DNS. The logic should be in the
> client behaviour. the SMTP protocol allows "Frank" to be a different
> email from "frank" so we cannot define these two to be the same at the
> protocol level. We can only provide guidance the clients trying to
> consume the new RRtypes.
Note that precisely because the client is not free to define "Frank"
to be the same as "frank", and because DNS does not have anything
remotely resembling server-defined case matching rules, we either
give up on supporting case-less matching even when case insensitivity
is known to the server, or multiple lookup keys need to be published,
in such a way that "frank" is explicitly lower-case-of(Frank) rather
than just some lower-case address.
> So I'm okay with defining client behaviour to try sha224(Frank) and then
> sha224(frank) and have a note in the security section explaining that
> in theory (even if not in practise) these two could be different people.
Once the client is making two queries, why accept collisions? Are
we (after all these years) finally defining RFC-822/2822/5322 local
parts to be case-insensitive? (Price of progress and all that?)
Is a CNAME per-user really a major burden?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
