Subject: [Gen-art] Gen-ART review of draft-ietf-sieve-managesieve-05.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 29 Dec 2008 10:23:04 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-sieve-managesieve-05.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 29 December 2008
IESG Telechat date: 18 December 2008
IETF LC End Date: 30 December 2008
Summary: The document is ready for publication as a proposed standard RFC.

Major issues: none

Minor issues:

- Section 1.2 could be slightly improved to guide the reader over the 
rest of the document by describing, at the very beginning, that "this is 
a command-response protocol based on a client/server architecture. The 
client emits a command; the server processes the command and replies with 
a response" (or something like that). I am also missing a sentence 
indicating that "the protocol runs over any connection-oriented transport 
protocol, although at the moment, TCP (and TCP over TLS) are the only 
defined transport protocols".

- Section 2.1 (towards the end) has a discussion about the STARTTLS 
command and the mechanism to protect against a MITM bid-down attack. The 
text says:

    Once a SASL security layer is established, the server MUST re-issue
    the capability results, followed by an OK response.  This is
    necessary to protect against man-in-the-middle attacks which alter
    the capabilities list prior to SASL negotiation.  The capability
    results MUST include all SASL mechanisms the server was capable of
    negotiating with that client.  This is done in order to allow the
    client to detect active down-negotiation attack.

What I am missing here is some normative text that instructs clients to 
do an action (which one would that be?) if such MITM bid-down attack is 
detected by the client. Nothing is written so far, and I suspect that 
client will not implement any action if it isn't clearly indicated.

Nits/editorial comments:

- idnits reveals that references [DIGEST-MD5] and [IANA-GUIDELINES] are 
declared in Section 9.2, but never used. There should be an anchor in the 
text or the reference should be deleted.

- idnits reveals that references to RFC 4366 and RFC 3280 are obsolete. 
The updated references are RFC 5246 and RFC 5280, respectively.

- there are a couple of "anchors" in the text. Just make sure these are 
deleted before publication, in particular anchor8, which describes Chris 
Newman's thoughts.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Dec 2008 17:51:48 +0300

> Summary: The document is ready for publication as a proposed standard 
Hi Miguel,
Thank you for your review!
> rest of the document by describing, at the very beginning, that "this 
> is a command-response protocol based on a client/server architecture. 
> The client emits a command; the server processes the command and 
> replies with a response" (or something like that). I am also missing a 
> sentence indicating that "the protocol runs over any 
> connection-oriented transport protocol, although at the moment, TCP 
> (and TCP over TLS) are the only defined transport protocols".
Ok, I will think about adding something like this.
> command and the mechanism to protect against a MITM bid-down attack. 
> The text says:
>
> What I am missing here is some normative text that instructs clients 
> to do an action (which one would that be?) if such MITM bid-down 
> attack is detected by the client. Nothing is written so far, and I 
> suspect that client will not implement any action if it isn't clearly 
> indicated.
Ok, I've added to my copy of the document:

    If a user-oriented client detects such down-negotiation attack, it 
SHOULD
    either notify the user (it MAY give the user the opportunity to
    continue with the ManageSieve session in this case) or close the 
transport
    connection and indicate that a down-negotiation attack might be in 
progress.
    If an automated client detects down-negotiation attack, it SHOULD return
    or log an error indicating that a possible attack might be in progress
    and/or SHOULD close the transport connection.
> Nits/editorial comments:
>
> - idnits reveals that references [DIGEST-MD5] and [IANA-GUIDELINES] 
> are declared in Section 9.2, but never used. There should be an anchor 
> in the text or the reference should be deleted.
I've removed the latter. The former is used in examples, so I should add 
formal references to it.
> - idnits reveals that references to RFC 4366 and RFC 3280 are 
> obsolete. The updated references are RFC 5246 and RFC 5280, respectively.
Updated.
> - there are a couple of "anchors" in the text. Just make sure these 
> are deleted before publication, in particular anchor8, which describes 
> Chris Newman's thoughts.