INBOME comments

[Daniel Kahn Gillmor]

Hi Neal--

On Tue 2016-12-06 08:54:10 -0500, Neal H. Walfield wrote:

> Unfortunately, it looks like I won't be able to attend the AME
> workshop.

sorry we'll miss you!

>  - Is there a reason to not build on the "The OpenPGP mail and news
>    header field" specification and instead invent a new header [2]?
>    (This specification doesn't support transferring the actual keys in
>    the headers.  Instead, a key identifier is specified and a URI
>    pointing to the key can be provided.)

It's conceivable that INBOME could work with S/MIME & CMS as well as
OpenPGP.  It's not clear that it must be OpenPGP-specific.

>  - I'm not sure that transferring keys in mail headers is a great
>    idea.  For instance, gpg's minimal version of my key is 4.8KB.
>    This is the binary version, i.e., it hasn't been ASCII encoded.
>
>    $ gpg --export-options export-minimal --export 0xAACB3243630052D9 | wc -c
>    4811
>
>    Do you not view this as a problem?

that's not sufficiently minimal ;)  the minimal openpgp cert for a given
e-mail address would be:

A * primary key
B   * user id
C     * self-sig
D   * encryption-capable subkey
E     * self-sig (no cross-cert needed)

so it should be about:

2*(sizeof key) + 2*(sizeof signature) + (sizeof uid).

for 3072-bit RSA, i agree that's large, but it's not even 2KiB.

for 25519 keys, that's less than 200B

>  - In the group communication example, Alice sends a message to Bob
>    and Carol at which point Bob and Carol learn about Alice's INBOME
>    preferences.  Why doesn't Alice also include Bob and Carol's latest
>    IMBOME header so that Bob and Carol can immediately learn about
>    Carol and Bob's keys, respectively, without additional
>    interactions?

While i think something like that could be useful, we need to be
extremely cautious about the consequences of allowing "drive-by" INBOME
data.  The analogy in the DNS world is "cache poisoning".  If i can set,
clear, or reset your INBOME data for someone else even if i don't have
access to the communitions channel, what are the consequences for your
future communications?

>  - When I described INBOME to Werner, he noted that adoption by mail
>    providers will probably be harder than convincing them to adopt
>    WKS.  I was initially confused by his statement, because INBOME
>    only requires that the MUAs be modified.  He then pointed out that
>    most users use webmail.  I'd be interested to hear about how you
>    plan to get INBOME widely adopted.

INBOME explicitly excludes full-webmail from its model.  This is a
simplifying assumption, and certainly it's possible that some webmail
implementers may want to provide hooks to interact with browser
extensions that do the inbome management.

But webmail itself is essentially in its design a provider-trust model,
which is not end-to-end.

fortunately, people are now used to installing "apps" again, as we
whipsaw back and forth between the merits of "thin clients" vs "local
processing", so punting on webmail seems ok for the meantime to me.

             --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20161206/efad97d8/attachment.sig>