I'd like finally to elaborate on just a couple more points: On Sat, Apr 18, 2020 at 10:47:58AM -0700, Kevin J. McCarthy wrote: > On Sat, Apr 18, 2020 at 08:41:47AM -0400, Remco Rijnders wrote: > > On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote: > > > I would also note that the current message id generation algorithm > > > is deterministic. It's easy to understand how it generates, and to > > > know the exact limitations where it might fail. Swapping out those > > > bits of uniqueness with a random() call takes away the determinism. > > > > > > The tiny (in my opinion too) information leaks, are not worth that > > > trade-off. > > > > I think having the message ID being non deterministic would be of > > greater value. The more deterministic it is, the easier it would be for > > someone to create a clash. > > The opposite, I would say. Unless you mean adversarially. But there is no > such threat model: I can easily steal your message id after you've sent the > email.
Note that what is deterministic is its uniqueness. Of course, if you
want to abuse the mail system, that's easy... you can tell Mutt to
always use the same message ID, for example. The main consequence of
this is that everyone you send mail to will see all your messages as
being the same message/thread, so it will give them headaches. But
you can do it, and the consequences are pretty minor. But Mutt wants
to be a good citizen of the e-mail community, so it will try hard to
meet the requirements established by that community, to prevent this
kind of nonsense.
> > I can't think of an example why someone would want to do that, but I
> > also can't really think of an example where a (fully) deterministic
> > Message-ID would be of value.
I think I just explained that. Message IDs overlapping breaks
threading. It also breaks tracing and debugging via logs, etc..
> The date/time partitions by time. The host by... host. The pid by mutt
> instance. The counter within a single instance.
>
> With this, I can say that two mutt instances on the same machine won't
> generate the same message id, even if they are sent within the same second.
> The same mutt instance also won't do that, unless you send >26 messages in a
> single second.
And let's be clear about what it would take to generate messages with
the same ID in Mutt:
- You need to generate > 26 messages in the same second--not any one
second, but XX:XX:XX.000000 - XX:XX:XX.999999. This is actually very
difficult to do.
+ You'd need to be watching the system clock to wait for XX.000000
+ Messages take time to be generated
+ Messages take time to be submitted to SMTP
+ A DNS lookup may be required, depending on settings
- You need to do it from the same pid
- You need to do it on the same machine
> Is this perfect? No. But your patch can no longer say even say that. It
> can merely say "probably".
It's pretty close to perfect. In order to generate the necessary
number of messages in the requisite 1s window, the easiest way would
be to write a script to generate 26 separate processes simultaneously,
but then each one would have a different PID field in their message
ID. To do it from the same process, you'd need a very fast machine,
a persistent connection to the SMTP gateway, and a very complicated
macro to create the messages as fast as possible.
In other words, the only way you're going to break Mutt's message ID
uniqueness is if you're actually trying to, really, really hard, and
probably not even then.
If you actually were trying to, it would be much easier to just use
$edit_headers and set it to whatever you want. Which is exactly what
you should do, if you care about this information leak.
> If there were a *real* threat model, Derek and I would take this more
> seriously. But I'm not going to backtrack on the generator determinism just
> to satisfy vague "security" threats.
Indeed.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
