On Sun, Mar 29, 2015 at 2:46 PM, John Levine <[email protected]> wrote:
> In article <CAMaMmn=g9FA2sYFzcnLgGCEfpnWFVb3sOwyPMr_g= > [email protected]> you write: > >For any set of aliases that are manually configured, publishing a key, or > >CNAME for each of those is of the same order of complexity as establishing > >the alias itself. > > For over a decade, I've been doing the common trick of inventing a new > address each time I sign up for something. Correct me if I'm wrong, but > you appear to be saying that now, I have to stop, go to some sort of DNS > provisioning system, tell it about the name I'm about to invent, publish > the new record, and wait for it to propagate before I can go back to the > web page where I'm about to use the name. > Also, I have no idea what all of the addresses are that I've made up > over the years, many of which still get mail from whoever I gave them > to. It appears I'm out of luck there. > I am not sure I understand the use case of wanting to enable opportunistic inbound encryption to all of the thousands of address that you can't even remember. But OK, is your use case is that you want keying (the same keying?) for all 500M potential variants? .... or just the thousands you have used? What about the person who might want different keying for his personal email and that of his mailing lists (assuming that is what many folks do with their aliases). Actually there are strict compliance implications about managing network identities in many commercial environments, where the idea that on is creating keying material for other, non explicitly created identities, won't fly. So if you enable key discovery and retrieval the 500M variants, please provide a mechanism to explicitly disable this feature too. As for DNS provisioning, none of this is going anywhere if there isn't significant automation between identity creation and keying. The vast majority of users don't even know there is a DNS. Personally, I am interested in enterprise-class solutions. Here if the DANE keying material is not dynamically updated from our identity/credential management system, it is a complete non-starter. > > >Unless your user agent generates a fuzzy match variant of your from: > >address outbound with each email, I am not sure that the scaling problem > is. > > There are plenty of mail systems that do that. Perhaps it would be > helpful to learn more about the way that modern mail systems work. > I am aware of how mail modern systems work (many have better ways of organizing email than generating thousands of addresses :). I was speaking of the hypothetical 500M algorithmic variants. I assume your mail system is not randomly generating your thousands of aliases. I am also aware of the problem I thought we were trying to solve. What I heard at the mic was that solving the general problem of keying that matches all the various local fuzzy matching rules of modern mail systems was either intractable, or outside the scope of DANE, or both. Let alone taking on the problem of those who don't want that behavior, or might want different keys on different local aliases. What I heard after the meeting on the list was some support of solving the simple problem in a ubiquitous way in DANE. I am guessing we would provide a solution that covers the vast majority of users with a simple one key per unique LHS. I think there may be support for solving the simple problem in DANE now. As for the more complex scenarios, it might warrant revisiting the use cases to understand the requirements, design trade offs of if, where and how the issue is addressed. > > R's, > John > -- DougM at Work
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
