Re: The problem we could solve (re github etc.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Jun 10, 2021 at 7:25 AM Alessandro Vesely <vesely@xxxxxxx> wrote:
On Wed 09/Jun/2021 23:48:30 +0200 Phillip Hallam-Baker wrote:
> On Wed, Jun 9, 2021 at 5:22 PM John C Klensin <john-ietf@xxxxxxx> wrote:
>
>> And I have a question: What does this rather long thread actually have to
>> do with the IETF other than demonstrating that it would be dumb for our
>> discussions to depend on a providers who intended to support those
>> discussions by selling subscriptions and/or tracking user behavior and/or
>> comments? >
> The reason I tried to bring it back to stuff that is in IETF scope was
> because I see all of these issues as being aspects of the same broken
> approach to Internet accounts.

There's a field in my Datatracker account linking to my GitHub account.  GitHub
has a field for linking Twitter accounts but not IETF ones.  In practice, I
sent the account name to the WG chair via an unsigned email message.  Is that
vulnerable to social engineering attacks?

What we need is a mechanism that allows us to link everything to a permanent identifier that belongs to the user and is thus immutable.

One option is a public key fingerprint. But that has user acceptance issues and PGP fingerprints have developed as an identifier that is subordinate to an email address which is the opposite of what we want.

We have to have names that look like 'alice', not a string of base32 characters.

One could find names at less that 1$, but then shouldn't expect to deliver much
of the mail sent from such domains.  The price we pay is for globalness and
some kind of moderation.

I spent 25 years working out how to validate keys that a user has attached to a name and it is near impossible without a national identity card level of effort and even then the result is limited. It gets us strong binding to the name holder which is rarely what we want for Internet stuff.

Then I flipped the problem round, what if instead of validating a key, we have a person use that key to claim a name to serve as an alias for that key on a first come first served basis. That is entirely tractable and doesn't require trusted third party, a Merkle Tree over an append only log is sufficient.

If every message was signed and mail messaging subject to access control, Alice is going to receive every message from Bob if shed decides to authorize him to send her mail.

SMTP is not going to be replaced overnight but I think that there might be a market for an email messaging service for important messages that is open, end-to-end encrypted and does not allow unauthorized parties to spam.


PHB

 

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux