[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-gellens-pop3ext-02.txt
At 1:08 PM -0800 3/12/98, Tom Killalea wrote:
>>5. The CAPA Command
>> The POP3 CAPA command returns a list of capabilities supported by
>> the POP3 server. It is available in both the AUTHORIZATION and
>> TRANSACTION states. Additional capabilities MAY become available
>> in the TRANSACTION state, but all capabilities listed in the
>> AUTHORIZATION state MUST also be available. If a capability
>> available in the TRANSACTION state is not available in the
>> AUTHORIZATION state, this MUST be stated in the capabilities
>I'm uncomfortable with the advertisement of TRANSACTION state-only
>capabilities while still in the AUTHORIZATION state.
>My concern is that potential attackers could use the information gleaned
>(including but not limited to IMPLEMENTATION information) to zone in on
>servers running vulnerable implementations, servers that implement XTND
>XMIT and are potential UBE injection points, etc.
>Maybe I'm paranoid (okay, I am), but I think it would be worthwhile to
>have two distinct commands, say CAPA and CAPT, for advertising supported
>capabilities available in the AUTHORIZATION and TRANSACTION states
There's nothing that requires advertisement in the AUTHORIZATION state. How
about listing this as a security concern? In the interest of simplicity, I
was hoping only clients looking for particular TRANSACTION state extensions
would have to do the second look up.
>> Section 3 describes the CAPA response using [ABNF]. When a
>> capability response describes an optional command, the <capa-tag>
>> is usually, but is not required to be, identical to the command
>> keyword. CAPA response tags are case-insensitive.
>the <capa-tag> SHOULD be identical to the command
>> S: IMPLEMENTATION "Shlemazle Plotz v302"
>Have I seen this before, Laurence ? :-)
It wasn't me despite previous geographic associations :-)
>>6. Initial Set of Capabilities
>> Note that there is no APOP capability, even though APOP is an
>> optional command in [POP3]. Clients discover server support of
>> APOP by the presence in the greeting banner of an initial challenge
>> enclosed in angle brackets ("<>"). Therefore, an APOP capability
>> would introduce two ways for a server to announce the same thing.
>I think that having two ways to announce the same thing is a lesser sin
>than returning an incomplete list with a dependence on another
>mechanism to complete the list.
Would be OK with me. I kind of agree with Chris who suggested taking it out
though. It's more code and complexity if the APOP options is advertised and
their's no cookie in the banner. You have to parse the cookie before the
options anyway. I can't think of any reason to have the cookie without