[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

[Jeffrey M. Vinocur]

On Wed, 3 Mar 2004, Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
> >> http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-01.txt

Note that I've snipped most of the suggestions below and have already 
incorporated them.


> > Section 3.1: I would omit 403 and 501 from the list, since they're
> > generic.  That's just a style issue, though.

*nod*  I do tend to reiterate that sort of thing needlessly.  In this 
case, though, where it seems realistic that they might actually be used, 
I think I want to explicitly remind client authors of the possibility.


> > Section 2: it's not clear from this document why STARTTLS is forbidden
> > after a successful authentication has been organised.
> 
> This is the way that STARTTLS is specified for other protocols.  I'm
> curious too why this is, and would love to hear more details, but I think
> it's important that we leave this in place.  [...]

I'll keep it for now, then.


> > Section 3.1: The sentence beginning "Clients MUST ..." should be removed,
> > since the base specification states which responses must be expected.
> 
> Agreed.

I kept that on purpose, because I thought the sentence forbidding 483 
was a bit of a non sequitor otherwise.  For reference:

     Clients MUST support other response codes by processing them based
     on the first digit.  However, the server MUST NOT return 483 in
     response to STARTTLS.  (See section 3.2.1 of [NNTP].)

Russ, if you still agree on removing it, just say so.

 
> > Section 3.2.1: Rather than "... it SHOULD do at least one of (1) close
> > ..."  I think you are better saying "... it SHOULD keep the connection
> > [text of (2)] or MAY close the connection [text of (1)]". That is, make
> > it clear that (2) is better.
> 
> Why is it obvious to you that (2) is better?  That's not clear to me; I'm
> not sure which of those is better and would want some practical experience
> first to be able to figure that out.

And if I had to guess what server authors are going to do, it'd be closing 
the connection.


> > Section 3.3: Please add an example that involves the 580 response
> > followed by another command.
>
> Agreed.

Looks good?

     Example of a failed attempt to negotiate TLS, with recovery of the
     underlying NNTP session:

        [C] GROUP local.confidential
        [S] 483 Encryption or stronger authentication required
        [C] STARTTLS
        [S] 382 Continue with TLS negotiation
        [TLS negotiation is attempted here]
        [Following failed negotiation, traffic resumes without TLS]
        [S] 580 TLS negotiation failed
        [C] GROUP local.public
        [S] 211 1234 3000234 3002322 local.public

 
> > Appendix: I suggest you add a formal specification similar to those in
> > Appendix D of [NNTP].
> 
> Agreed.

Feedback welcomed:

     o  The STARTTLS extension provides connection-based encryption via
        Transport Layer Security (TLS).

     o  The extension-label is "STARTTLS".

     o  The extension-label has no arguments.

     o  The extension defines one new command, STARTTLS, whose
        behaviour, arguments, and responses are defined in Section 3.

     o  The extension does not associate any new responses with pre-
        existing NNTP commands.

     o  The extension does affect the overall behaviour of both server
        and client, in that after successful use of the new command, all
        communication is transmitted with the TLS layer as an
        intermediary.

     o  The extension does not affect the maximum length of commands and
        initial response lines.

     o  The extension does not alter pipelining, but the STARTTLS
        command cannot be pipelined.

     o  Use of this extension does alter the output from LIST
        EXTENSIONS; once the new command has been used successfully,
        this extension can no longer be advertised by LIST EXTENSIONS.

     o  The extension does not cause any pre-existing command to produce
        a 401, 480, or 483 response.

     o  The LISTGROUP command can be used before or after the MODE
        READER command, with the same semantics.



-- 
Jeffrey M. Vinocur
jeff at litech.org