Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To replaceme nt text)

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Tue, 1 Jun 1999 18:52:35 -0700

> 1-1-1970 + process
> > ID), there is still a window (albeit a very small one) 
> where two clients
> > that happen to get the same process ID in the same second 
> could generate the
> > same message ID.  
> 
> on reasonable systems, there's no way two different clients 
> could get the
> same process ID.  so message-id collisions would require time 
> warps across 
> reboots or across process-id wrapping.  no it's not impossible but 
> the cases where message-id collisions happen "by accident" are far
> fewer than the cases where they happen as a result of ignorance on
> the part of the programmer.

Cool - I didn't know that there were "reasonable" operating systems out
there that actively worked to prevent handle re-use across time - most of
the system's that I've dealt with form the process ID as a varient of an
index into an internal process table (it may be generated by the same handle
generation algorithm used for file handles, it may be some other mechanism,
but it usually boils down to some form of an index into some table) , and
there's nothing preventing such a system from serially issuing the same
process ID to two different processes (of course the process load time has
to be fairly quick on the machine, but....).

> 
> I agree that this is probably sufficient for the purpose of 
> message-id,
> and there is some precedent for it in MIXER's use of X.400 message-id
> followed by "@MHS".
> 
> so should RFC822-bis also include a warning about the 
> security risks of
> basing message-ids on hardware serial numbers (as in when 
> UUIDs are used)?

Only if DRUMS also includes a warning about the security risks of including
a dns name in a message-id.  The risks are equivilant, in either case, you
are stamping the message ID with an "authorititative" indication of where
the message ID was generated.  The only difference is that the hardware
serial number in the UUID is less in-your-face than the DNS name.  UUIDs
have a slight additional risk that you have the ability to determine the
vendor-ID of the networking hardware (or CPU if it's based on a CPU serial
number) that was used to generate the UUID, however on many systems with
built-in networking hardware (most of the MIPS machines I've worked with,
for example) the vendor ID on the network card is programmable (don't go
there, I know that setting the vendor ID renders UUIDs non unique).

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Jun 1999 22:45:58 -0400

--On Tuesday, June 01, 1999, 18:52 -0700 "Larry Osterman (Exchange)"
<[email-masked]> wrote:

> index into an internal process table (it may be generated by the same
> handle generation algorithm used for file handles, it may be some other
> mechanism, but it usually boils down to some form of an index into some
> table) , and there's nothing preventing such a system from serially
> issuing the same process ID to two different processes (of course the
> process load time has to be fairly quick on the machine, but....).

FWIW, the usual tricks are to build the process ID from some catenation or
hash of 

   --   that index or the equivalent
   --  the processor ID (in a potentially multiprocessor  or clustered
                  environment) -- more often a sequence number 
                  in the group/cluster than a global serial number.
   -- either the date-time the system came up and the table was created 
                 or the date-time the process was created, either one to 
                 reasonably fine resolution.

i.e., getting/keeping them long-term unique is a lot short of rocket
science.

    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 01 Jun 1999 22:44:56 -0400

> there that actively worked to prevent handle re-use across time 

I don't know of any UNIX systems that can reuse the same PID within a 
tick of the system clock.  so if you do PID + clock + per-process 
serial #, you're in good shape.

> > so should RFC822-bis also include a warning about the security risks of
> > basing message-ids on hardware serial numbers (as in when UUIDs are used)?
> 
> a dns name in a message-id.  

seems fair.

Keith

---

From: Brad Knowles <[email-masked]>
Date: Wed, 2 Jun 1999 11:41:41 +0200

> there that actively worked to prevent handle re-use across time

	I think you need to re-read his message.  The likelihood that a 
32-bit (or even 16-bit) pid will wrap in the space of a single second 
is highly unlikely.  The likelihood that even a 128-bit pid will wrap 
sometime within the history of the Universe (way, way, way, way, way 
in the future ;-) is 100%.

	Thus, message-id generation schemes that include both the pid and 
the date/time (down to the second) are highly likely to avoid 
collision, at least within that particular machine.

	However, as we get into SMP and distributed machines that present 
one view of process space to the user, we need to ensure that the 
recommended message-id generation algorithm includes additional 
sources of information so as to sufficiently uniquely identify the 
message.

>                                The only difference is that the hardware
> serial number in the UUID is less in-your-face than the DNS name.

	For those who are participating in the "Boycott Intel" effort, I 
would submit that precisely the reverse is true.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin      Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.