Re: Some security-related suggestions

Ned Freed <> Wed, 08 June 1994 20:25 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06462; 8 Jun 94 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06458; 8 Jun 94 16:25 EDT
Received: from ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa13899; 8 Jun 94 16:25 EDT
Received: (from postman@localhost) by (8.6.7/8.6.6) id QAA13653; Wed, 8 Jun 1994 16:18:02 -0400
Received: via switchmail for; Wed, 8 Jun 1994 16:18:02 -0400 (EDT)
Received: from via qmail ID </afs/>; Wed, 8 Jun 1994 16:17:18 -0400 (EDT)
Received: from (SIGURD.INNOSOFT.COM []) by (8.6.7/8.6.6) with ESMTP id QAA19009 for <>; Wed, 8 Jun 1994 16:16:57 -0400
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HDALGWTSDS9KM0RO@SIGURD.INNOSOFT.COM>; ) id <Wed, 8 Jun 1994 13:16:31 PST
Date: Wed, 08 Jun 1994 13:07:06 -0800 (PST)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <>
Subject: Re: Some security-related suggestions
In-reply-to: Your message dated "Wed, 08 Jun 1994 15:22:29 -0400 (EDT)" <>
To: John Gardiner Myers <>
Cc: POP3 IETF Mailing List <>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT

> I consider these all implementation issues.  There's no reason to
> require these measures in the spec.

Actually, there is. Current IESG rules state that all known "security issues"
associated with a protocol must be discussed. Actually recommending solutions
to problems is not required, but a description of the issues is. However, if
you say

   "Providing an indication of the existence of an account in the absence of
   a proper password lets attackers narrow the search to known accounts, and
   thus represents an increased security risk." 

which could very well be construed by the IESG as being required, but then you
don't say that the way to prevent it from happening it to not acknowledge the
nonexistance of a username, you're being kind of stupid, don't you think?

Having seen several effective attacks based on nothing more than examination of
server process characteristics after a user-password sequence has been entered,
I for one don't think this sort of prose is at all unreasonable. In fact, I
know of one attack that actually managed to ferret out the password one
character at a time by looking at certain system statistics.

Finally, having gone through all of this with MIME, where the section on
PostScript security was written for very similar reasons, I see no need to
repeat the process and incur additional delays with POP3.