[ame2016] INBOME comments

[Neal H. Walfield]

Hi Vincent,

On Tue, 06 Dec 2016 16:28:41 +0100,
Vincent Breitmoser 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.)
> 
> A quick grep on my Maildir for OpenPGP header reveals a host of
> different formats used in the OpenPGP header, including all combinations
> of short/long key ids, fingerprints in different formats, and urls to
> keyservers, keybase profiles, and other urls with keyblocks or related
> data.
> 
> Current versions of Enigmail offer setting the content of this header
> field as a free text setting (although this changed(?) recently[1]),
> which generates a lot of noise there. I imagine some people have
> customized scripts for interpreting the header on the receiving side,
> too.
> 
> It's worth considering, but I'm not seeing an upside other than the
> simple name, compared to just using a new header where we don't clash
> with existing expectations and practices.

Just because you have a standard doesn't mean that everyone is going
to follow it.  So, in the end, INBOME code will still have to deal
with non-conforming content.

In that regard, creating a new, very similar standard only has the
disadvantage of creating a new standard.

> >  - 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.
> > 
> >    Do you not view this as a problem?
> 
> This is indeed a thing we have to talk about more, and mention in our
> drafts at least!
> 
> One argument is that a few kb of data (10kb at worst) really are not
> much of a technical anymore, but rather fall in the area of principle by
> modern standards.  
> 
> As a shorter term mitigation, keys can be minimized further: We can drop
> all subkeys besides the ones we actually want to use (in your case that
> drops the auth key at least), we can also drop all user ids beside the
> one we use in the email. Your key also has the peculiarity that it has a
> signing subkey where the primary key can also sign (and is probably
> picked to sign messages, unless the subkey is specifically selected?),
> which means we could also drop that one.
> 
> The mid term solution certainly is to switch to ecc.

Sure.  But in the end, you really want to get the whole key from the
key servers anyway in which case the fingerprint is enough.  First,
having all of the data, you can potentially determine that a key is
trusted.  Second, you need to periodically refresh the key to discover
any revocation certificate (or is INBOME propagating them?).

> >  - 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?
> 
> This type of gossipping is problematic because it trivially allows
> injecting keys for other people, without even spoofing the message
> sender address. Holger brought this up before and probably spent more
> time thinking about this than me though :)

I tried to address this in my reply to dkg (Message-ID:
<87lgvs0zpn.wl-neal at walfield.org>).


Thanks!

:) Neal