[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