Just to be clear, I was not suggesting that DNS be the mechanism, just that there was a dns-like service that drove the process.
Mail servers could run this service. However, they would not have to. Since the keys are a security issue on several fronts, it would be wise to keep it as a separate service that you can maintain with somewhat high security monitoring. On Fri, Jan 10, 2020 at 12:21 PM Tomas Kuchta <[email protected]> wrote: > I do not think DNS is the correct kitchen sink for user's public key > distribution. The infrastructure and service costs would not be scalable. > > Email servers are the obvious target for this - it is distributed, owner > bears costs and does not need middle man. > > Just my 2c, > Tomas > > On Fri, Jan 10, 2020, 15:13 John Sechrest <[email protected]> wrote: > > > If you had a key registry of some kind, then just like DNS gives you an > IP > > number for a name, you could get a key for a user, and you would have a > > mechanism for sharing the encryption as it changes. Since you articulated > > earlier that my keys are likely going to be changing over time. So then I > > need to put a form of key evolution into this system. > > > > And since we are worried about security in this, we have to find ways to > > make the DNS-for-encryption-keys be secure and immutable, otherwise, it > > just becomes a different vector for descryting by the wrong people. > > > > > > > > On Fri, Jan 10, 2020 at 12:08 PM Paul Heinlein <[email protected]> > > wrote: > > > > > On Fri, 10 Jan 2020, John Sechrest wrote: > > > > > > > I have the feeling that the PGP process is not more widely adopted > > > because > > > > of the user experience. You have to go out of your way to get things > up > > > and > > > > going. And then you have to be attentive. > > > > > > > > It would be interesting to take this "idea toolchain" and come at it > > > from a > > > > perspective of the user experience in the process. > > > > > > > > I would submit that if I need to be intentional about keys, privacy > and > > > > trust in each transaction that the adoption rate will be very low > (As I > > > > think we see with pgp) > > > > > > > > Are there ways to fold the "User Actions" into a process, so that the > > > task > > > > of engaging in messaging is secure and yet does not take substantial > > > > intention to keep things going. > > > > > > Longer ago than I care to admit, Simson Garfinkel and I exchanged some > > > ideas on this theme. His idea, which I thought promising, was to treat > > > secure e-mail exhanges like SSH logins. > > > > > > The first time I log into a remote host using SSH, I'm asked to accept > > > the key. It's certainly possible to request that key from a trusted > > > third party (even DNS), but usually I just accept the key on first > > > login. I only worry about it when it changes and SSH issues its > > > impossible-to-ignore WARNING WARNING message. > > > > > > His thought was that the first time you exchange an e-mail message > > > with someone, you accept that user's key (automatically offered up by > > > a process or protocol that doesn't yet exist). The remote user does > > > likewise. Thereafter, all communications with that person are > > > encrypted by that key. Should the key change, the mail client would > > > turn red or otherwise indicate WARNING WARNING. It would be up the > > > local user to decide if the key change is valid or not. > > > > > > There are obvious potential problems with this idea: there's no > > > obvious way to publish keys beforehand; it's unclear how to deal with > > > people who use multiple mail clients (phone, tablet, home workstation, > > > work workstation, web client) with the same e-mail address; too many > > > people will ignore WARNING WARNING and thoughtlessly accept the > > > change; and many others. > > > > > > Still, I thought it was on the right track toward just building > > > point-to-point crypto into the scheme of things. > > > > > > -- > > > Paul Heinlein > > > [email protected] > > > 45°38' N, 122°6' W_______________________________________________ > > > PLUG mailing list > > > [email protected] > > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > > > > > > > -- > > John Sechrest . Need to schedule a meeting : > > http://sechrest.youcanbookme.com > > . > > . > > . > > > > . > > [email protected] > > . > > @sechrest <http://www.twitter.com/sechrest> > > > > . > > http://www.oomaat.com > > . > > _______________________________________________ > > PLUG mailing list > > [email protected] > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > -- John Sechrest . Need to schedule a meeting : http://sechrest.youcanbookme.com . . . . [email protected] . @sechrest <http://www.twitter.com/sechrest> . http://www.oomaat.com . _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
