Subject: [secdir] secdir review of draft-ietf-sieve-managesieve-06

From: Tobias Gondrom <[email-masked]>
Date: Tue, 06 Jan 2009 17:07:29 +0100

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

The draft has been updated to version 06 on Jan-1 2009, so this review
is on this current (and most recent) version.

This document contains a security sensitive protocol.
I suggest the following comments be discussed before publication.

COMMENTS:
1. Section 1.3
s/This a line oriented protocol much like [IMAP] or [ACAP]./This is a
line oriented protocol much like [IMAP] or [ACAP].

2. The design decision to use CRLF as a separator for a protocol seems a
bit odd, different OS might use different means to signal a CRLF. IS
there potential for misinterpretation?

3. section 1.3:
If a server has an inactivity timeout resulting in client autologout it
MUST be no less than 30 minutes after successful authentication.
QUESTION: Why 30 minutes????

4. TRANSITION-NEEDED
this command seems to be there as a kind of bypass, the reason why the
client should be informed of the validity of a username in this case is
not clear to me? Could the client not just be returned a deny and it has
to try the alternate authentication?

5. Section 1.8:
Question for my understanding about:
“STARTTLS - If TLS [TLS] is supported by this implementation.  Before
   advertising this capability a server MUST verify to the best of its
   ability that TLS can be successfully negotiated by a client with
   common cipher suites.  Specifically, a server should verify that a
   server certificate has been installed and that the TLS subsystem has
   successfully initialized.  This capability SHOULD NOT be advertised
   once STARTTLS or AUTHENTICATE command completes successfully.  Client
   and server implementations MUST implement the STARTTLS extension.”

At the beginning of the paragraph it is stated “if TLS is supported” and
at the end of the paragraph it is stated that “client and server
implementations MUST implement ...”. So is there a case where it is not
implemented/supported?

6. the VERSION capability:
“Lack of this capability means that the server predates this
specification and thus doesn't support the following commands:
RENAMESCRIPT, CHECKSCRIPT and NOOP.” the first part of the sentence is
ok, but I should not define which functions are not supported for a
protocol outside of the scope of this standard (without the VERSION
command). Implementations outside could have any behavious which should
not be guessed (although I assume there is one test implementation by
the authors of the draft which behaves as described...)
As it clearly states in the draft: “A server implementation MUST return
SIEVE, IMPLEMENTATION and VERSION capabilities.”

7. and last but not least in section 2:
“Prior to successful authentication only the AUTHENTICATE, CAPABILITY,
STARTTLS, LOGOUT and NOOP “
QUESTION: Why is NOOP available unauthenticated? This seems like a
potential unnecessary DoS vulnerability?
QUESTION: Why is LOGOUT available unauthenticated?

Best regards, Tobias

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 7 Jan 2009 15:41:23 +0100

Hi Tobias,
Thank you for you review! My comments are below:

> line oriented protocol much like [IMAP] or [ACAP].

Fixed, thanks.

> bit odd, different OS might use different means to signal a CRLF.

It is not odd, it is very common in text based protocols, especially email
related (just to name some: IMAP, POP, SMTP)

> IS there potential for misinterpretation?

No. CRLF is always a 2 byte sequence. Neither bare CRs, nor bare LFs are
allowed as end of command/response delimiters.

> QUESTION: Why 30 minutes????

30 minutes is used by IMAP. The value is somewhat arbitrary, but it is in
the document in order to improve interoperability: a client that uses long
lived connections will have to issue a command before timeout is over (or
deal with the server disconnecting the client).

> to try the alternate authentication?

Handling of this response code in the client might be different from the
standard handling of a failed authentication. Thus the response code.

When the client sees the TRANSITION-NEEDED response code, it can try PLAIN
right away. But if it doesn't, it might end up unnecessary trying other SASL
mechanisms that would fail in the same way.

But yes, there are security implications of using this response code. Not
every server developer would chose to implement it.

> "STARTTLS - If TLS [TLS] is supported by this implementation.  Before
>   and server implementations MUST implement the STARTTLS extension."
>
> At the beginning of the paragraph it is stated "if TLS is supported" and
> at the end of the paragraph it is stated that "client and server
> implementations MUST implement ...". So is there a case where it is not
> implemented/supported?

No.
The requirement to require TLS came later on, so in some places the text is
not fully updated.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 7 Jan 2009 19:41:46 +0100

Hi Tobias,
The second part of my reply is below:

On Tue, Jan 6, 2009 at 5:07 PM, Tobias Gondrom
<[email-masked]>wrote:

> "Lack of this capability means that the server predates this
> RENAMESCRIPT, CHECKSCRIPT and NOOP." the first part of the sentence is

Multiple existing implementations behave as described.
I think it is important for the document to provide some guidance for client
and server implementors that want to interoperate with (or upgrade) deployed
software.

> As it clearly states in the draft: "A server implementation MUST return
> SIEVE, IMPLEMENTATION and VERSION capabilities."
>
> "Prior to successful authentication only the AUTHENTICATE, CAPABILITY,
> STARTTLS, LOGOUT and NOOP "
> QUESTION: Why is NOOP available unauthenticated?

This was modelled on IMAP, which allows for NOOP in unauthenticated state.

> This seems like a

Can you elaborate on what kind of DoS you had in mind?

> QUESTION: Why is LOGOUT available unauthenticated?

 I don't see why this might be problem. LOGOUT is a nice-to-the-server way
to shutdown a ManageSieve connection.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir