Am 18.04.20 um 19:47 schrieb Kevin J. McCarthy: > 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. > >> 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. > > 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. > > Is this perfect? No. But your patch can no longer say even say that. > It can merely say "probably". > >> In my opinion my patch reduces the complexity of the code, albeit in >> a neglectable way, and also addresses the concerns about information >> being leaked even when these concerns might be considered tiny or >> pointless by you/Derek/some/most. > > But not without compromising the primary purpose of the id: to be unique. > > 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. > There is a possibility that if mail-to-news gateways are involved, that then a prediction of Message-ID generation can be abused to collide Message-IDs and hence suppress messages sent by the victim from appearing on Usenet. That works by the attacker posting to some noise messages with predicted Message-IDs to some random newsgroup, and the victim's messages then get rejected by duplicate elimination (i. e. news servers won't accept a message with a Message-ID they've already seen elsewhere), and can only be found out systematically if the victim regularly inquires his part of Usenet somehow to see if under his Message-ID there are his own posts and not colliders.
A random part in the Message-ID would considerably reduce this attack surface.
