[ame2016] INBOME comments

Neal H. Walfield neal at walfield.org
Thu Dec 8 10:25:13 CET 2016


On Wed, 07 Dec 2016 23:35:45 +0100,
Daniel Kahn Gillmor wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain (7bit)>]
> On Wed 2016-12-07 08:37:39 -0500, Vincent Breitmoser wrote:
> >> For RSA keys, that's still a fair amount (i.e., too much, IMO).  For
> >> ECC keys, it is reasonable.
> >
> > I found this iffy as well, until it occurred to me that 2kb attachments
> > sounded fine, and that headers aren't worse than attachments in terms of
> > mail size. Someone (dkg?) also mentioned that we certainly wouldn't be
> > the first to use large headers for things, I think their example was
> > Microsoft.
> 
> I've got a local example of mail sent between two microsoft exchange
> servers.  All the headers on a single message come in total to 24613
> octets(!)
...
> INBOME could hardly do worse than this kind of bloat.

Thanks for this data point.

> > More importantly though, we have to avoid unreadable messages. Nothing
> > makes a user drop a system faster than a reply "sorry couldn't read
> > that". Allowing gossip will increase the rate of that happening, since
> > the user's own MUA has less direct control over session negotiation.
> 
> I tend to agree with this analysis.  if we assume that INBOME can never
> protect the first message with a new communications partner, we gain
> quite a lot of usability and avoid a lot of potentially nasty pitfalls.
> This isn't ideal, but neither are the usability problems :)

I see the point, but I'm not entirely convinced.  Unfortunately, I
don't have any strong arguments.  Anyway, it is rather minor in the
scheme of things.

Thanks!

:) Neal



More information about the Gnupg-devel mailing list