ietf-nntp draft-ietf-nntpext-tls-nntp-00

[Jeffrey M. Vinocur]

On Mon, 3 Mar 2003, Ken Murchison wrote:

By the way, it's generally easier for everyone to keep track of what's
going on if you separate issues into multiple message.


> First a few nits:

Fixed, thanks.


> -section 4:  You should state that TLS negotiation begins immediately
> after the CRLF at the end of the 382 response from the server.  You also
> might want to mention that if the client is pipelining commands (per the
> description in base-17), that the STARTTLS command MUST be the last
> command in a group.

Oo, I hadn't seen the new text about pipelining.  Yes, I'll add "MUST NOT 
be pipelined" to the very start of section 4.


> - section 4.1:  

I'm going to yield to Russ on the response codes.  I think he'd approved
the usage in the draft, but I'd have to dig up the exact justification.

You're right that the inadequate-security response code (here 483) isn't 
formalized, anywhere.  That slipped through when I pulled out the SASL 
stuff.  But it's an interesting issue:

Is it acceptable to formalize 483 here, even though -- once the SASL stuff 
is in place -- both STARTTLS and AUTHINFO SASL will be acceptable actions 
for the client to take after receiving 483?


> - section 4.3:  Why reissue the welcome banner?  What is its purpose? 
> None of the other messaging protocols do this.  

Hmm.  It's existing practice with the TLS-on-port-563 implementation, 
since otherwise there's no welcome banner at all (because the TLS 
negotiation begins immediately).  I haven't actually checked what INN does 
if you use STARTTLS...I believe it does not reissue the banner.

I'm willing to change this if the group agrees.


> - section 4.3:  Instead of flushing the authentication info, why not
> just say that the STARTTLS command is only valid in the
> non-authenticated state (didn't we already decide that we shouldn't
> allow multiple authentications)?  RFC 2595 does this.

People?


> - section 5:  I'm not sure that documentating an extension that will be
> obsoleted by a TLS extension (IMO this functionality _belongs_ in TLS
> and not the application layer), and which can be accomplished by an
> existing command (AUTHINFO USER), make much sense.  It seems that this
> will be a little used interim extension at best, and uncessary clutter
> at worst.  But I'll defer to WG consensus on this.

The point I was trying to make in the "Note" at the top of section 5 was
that I expect (and hope) to remove this extension, and that nobody should
implement it except out of boredom.  I just found out about the TLS
extension recently (recall that STARTTLS has been in pre-draft stage for
an absurdly long time), after MULTIDOMAIN was specified.  So I debated
removing it before sending the draft, but ended up compromising on leaving 
it with that note.

Also, I have no sense of the timeframe of expected finalization of the TLS 
extensions, and didn't want to commit to relying on them without further 
information in that regard.  If you can supply details here, that would be 
great.


-- 
Jeffrey M. Vinocur
jeff at litech.org