Re: Identify AI bots in emails at IETF?

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Oct 14, 2019 at 6:03 AM Eliot Lear <[e-mail]> wrote:

> It’s a fun question, and there is (at least to me) an obvious answer.  In
> the good old days we used to have key signing parties at the IETF, and it
> would be possible for people to attest that I am indeed me and you are
> indeed you.  That way, at least you could see by people’s signatures
> whether or not there was someone who signed their key who you knew.
>
> The problem is that the UX would have to keep up with that.  I’m not sure
> it’s quite up to the task.
>
> Eliot
>

What if we could have an automatic key party when people register?

This is not something the Mathematical Mesh currently supports but it is
certainly one of the things the infrastructure is designed to support. And
as it happens we are having a MATHMESH BOF in Singapore.

The goal of the Mesh is to make computers easier to use by making them more
secure, which demands a really low level of demand on the attendee. And
here the point is not to only provide a feature for IETF use, the point is
to provide a mechanism that can support validation of people within a PKI.

The TLDR here is: QR Codes, Blockchain, mobile app, kiosk in registration
area. Needs graduate students willing to write some code and do integration.


I just recorded a video giving an outline of the design but it will be a
while before I get round to editing it. Here is a brief summary of the
proposal.

Objective: Establish that a person attended IETF without necessarily
verifying the identity of that person with respect to government issued
credentials.

1) Assume that people have a Mesh Client Application on their mobile device
which has the ability to scan QR codes.

2) Assume that there is something that looks like a picture frame in the
registration area. To claim attendance at the IETF, Alice (the attendee)
opens up her Mesh Client App and scans the bar code. She is told if she
were successful or some error occurred but that is the extent of the
interaction.

This interaction is of course merely one particular specialization of a
generic interaction for exchanging contact information via a mobile phone
'bump'. This is something we should have established as a standard long
ago. One of the major Internet companies got very excited about this a few
years back. Unfortunately the excitement took the form of buying a company
'to make it happen', pulling the existing app from the stores and then
losing interest.

So what happens at the protocol level?

0) The application has a public/private key for signing that is
credentialed under Alice's personal Mesh

1) The QR code contains UDF of the form
udf://example.com/EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q

This changes at regular intervals so each attendee will register to a
different code.

2) Following the process described in:
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/

This is transformed into the following URL and resolved.

https://example.com/.well-known/mmm-udf/MDWZ-WDB7-FZLG-46QL-UURR-FQ36-UQ2A-6YIX-BG4T-32A2-QHPE-5UPP-MMKA-3YR2

The returned data is a DARE envelope. This is decrypted using the
key EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q and the Message Authentication
Code verified.

3) The decrypted document is a JSON encoded structure yet to be defined
that gives the client a Mesh Service Account identifier, (
[e-mail]), a PIN code (NC6B-EYP6-O3JR-54HY-IE45-FOUU-TIPQ)
and an indication this is a notarization event.

4) The Mesh Client makes a contact notarization request to
[e-mail]. This is signed by Alice's device key

5) The contact notarization request is enrolled in the example.net
notarized log. Which is a DARE Sequence verified by a Merkle Tree. This may
or may not be made public.

[Optimizations are possible here, the picture frame doesn't actually need
network connectivity. When it is turned on the first time, the admin scans
a QR code which causes a shared secret to be passed to the example.net
service and this is used to generate the QR code and other data via a
counter and a KDF.]

So what do we get from all this?

Assuming that the example.net notarized log is cross notarized with other
authorities, the work factor for defection increases to an infeasible level
very very quickly. So Alice can establish that her phone 'bumped in' at the
registration desk. We can have separate discussion of how public this
should be and whether we want to have binding factors, zero knowledge and
such (more grad student projects).

The amount of validation we get from a single unverified bump in is small.
But if we do it every meeting, it can rapidly mount up. Someone who has
bumped in at a dozen IETFs... that alone is pretty compelling that there is
a person there, not a bot. Someone who have bumped in at a variety of
different conferences, RSA and IETF and ICANN, much stronger still.

Now assume everyone is using the Mesh, it is a part of the Android and iOS
operating systems, etc. We can make bump-in the default means of
registration for the conference. Instead of being a standalone display in a
picture frame sorta thing, the QR code generators are linked in to the
conference reg system so that when I bump in, my badge starts printing or
it appears on the console of the person with that box of badges.


And one more thing,

One of the things that irritates me about public events is that everyone is
on their phone taking not very good pictures. And they only get one set of
pictures from one angle at best. What if we could share and it was painless
to do so?

When I bump-in, I could collect a URL for a Web site with photos for that
event that people have uploaded. And I can upload my own (if I choose). So
we get the gift exchange going.

And of course, since it is the Mesh underneath, we can exchange encrypted
documents. I have been thinking a lot about the 'revenge porn' issue of
late and think I have some answers there.