[ame2016] INBOME comments

[Daniel Kahn Gillmor]

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(!)

The X-Microsoft-Exchange-Diagnostics and
X-Microsoft-Exchange-Diagnostics-untrusted headers alone (there are 8 of
each of them) account for 15548 octets.

It looks to me like MS is breaking up the data they're hoping to
transmit in these headers into lines that (if unwrapped) would still be
within the SMTP 998 character limit and then just jamming as many of
the headers as needed into the message's header block.

They clearly don't care about optimizing for message size either --
here's an example header:

X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BCY1PR0101MB1433=3B7=3AZ?=
 =?us-ascii?Q?XImAua4ISksmNlG7KqZAmkCutHAJo1N1fbwUWvnjJ7KjW48Etwx6N5T/5Uio?=
 =?us-ascii?Q?CQiEHVP+5lnS+nsWWnojFKVE7Jtc9dsDK/iHeIigDQ+5hYp3SucDX5N0g2Y2?=
 =?us-ascii?Q?JTp3D6BMumpWytQmO5VRGKOhOCflWlph4aJlmGG6Gd3UYBKvvve+kdF0ZRnX?=
 =?us-ascii?Q?D9/kXlksE00+1XSGwG0Q5mjT5WEdklY13n+4fxyaAnIATrxw+XuzYUGTUAX2?=
 =?us-ascii?Q?LNiY1P3XULtF73KXVvwHcY4r+sdM2TTkOxoHvyQTxuTW81HIaf+nfeeHVtHJ?=
 =?us-ascii?Q?5SetkD912B7+iGsJHHbIDFh0AJNMeNej7RcqpZnVW93dHDUqtdMcj7rMn5SE?=
 =?us-ascii?Q?XoqnR6jltKvx029Qjh9Depad7FD3gGkTcdP7GX6jotbI/fQHC4yP/DqmGYcl?=
 =?us-ascii?Q?7nyrxDmw6YlgP+zPv4/od3tZohrvQ0IE6jQEKJxK485tjPD39gdTKt8jWu8i?=
 =?us-ascii?Q?YghxwyX2rY=3D?=

it looks to me like they've taken an original binary thing, and then
wrapped it in several layers of base64-encoding, quoted-printable
encoding, and RFC 2047 encoding.  I haven't bothered trying to decode it
all the way down, so hopefully i'm not leaking anything dangerous by
publishing it here ;)

INBOME could hardly do worse than this kind of bloat.

> 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 :)

          --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/20161207/8afff2fd/attachment.sig>