INBOME comments

[Neal H. Walfield]

On Tue, 06 Dec 2016 16:58:46 +0100,
Daniel Kahn Gillmor wrote:
> On Tue 2016-12-06 08:54:10 -0500, Neal H. Walfield wrote:
> >  - 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

For RSA keys, that's still a fair amount (i.e., too much, IMO).  For
ECC keys, it is reasonable.

> 
> >  - 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?

Well, this is opportunistic encryption so what are the consequences?
I think the worst case, is that Bob sends an encrypted message to
Carol using the wrong key.  In that case, Carol replies that she could
not decrypt the message at which point Bob has the right INBOME
information and can securely resend.

I think that this situation can also arise even without this type of
gossip: someone just needs to send a forged mail.

In practice, I would track the origin of the header and prefer the
header from the actual recipient.

:) Neal