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

[Jeffrey M. Vinocur]

On Mon, 3 Mar 2003, Ken Murchison wrote:

> "Jeffrey M. Vinocur" 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.
> 
> Since these are all related to one command, it never even occurred to me
> to separate them.

Yeah, I know.  But I think at least a few of us use our inboxes as todo 
lists, and it's hard to follow an issue through a bunch of traffic that's 
programatically indistinguishable because it's in the same thread.

(Which is, of course, indicative of the non-optimality of the form of 
communication we're using, but it's what we've got.)


> > 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?
> 
> Hmm, good point.  I would argue that this is an AUTHINFO specific
> response code and belongs in the AUTHINFO draft.

But it's not, really.  A server can implement STARTTLS using 483 and not 
support any form of AUTHINFO at all.  Fun, eh?

And I don't want to have this draft blocked on the other.  So I suppose 
I'll just standardize it in both with similar language; that shouldn't 
confuse anybody.


> I do think we should have a "TLS failed" response code.

Do both the client and server know on which octet normal data resumes 
after a failed negotiation?


> Keep in mind that the banner that you see when doing NNTPS (port 563) is
> the _actual_ greeting banner.  The SSL/TLS negotiation happens outside
> of the actual NNTP protocol (its an NNTP session nested inside of
> SSL/TLS), where STARTTLS happens within NNTP.  Even though the SSL/TLS
> code is essentially the same, NNTPS and NNTP/STARTTLS are apples and
> oranges.

Oh, I know.  Just explaning where that came from.

Ok, I'm going to change it to indicate that the server MUST NOT issue a
banner.  (I hope nobody implements it with the banner in the mean time, 
might confuse clients.)

It's sort of a shame that we don't have a chance to send 200 or 201 again, 
but we don't get to after authentication either so I guess the milk is 
already on the floor.


> > 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 understand the point of the note, I guess I'm lobbying to have this
> functionality taken care of by TLS.

Oh, I agree.  


> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg22586.html

Wonderful.

Ok, I will remove MULTIDOMAIN from the STARTTLS draft.  I can't decide
whether we have consensus or just apathy in the other thread (virtual
hosting in NNTP); if people want a standalone command similar to 
MULTIDOMAIN from this draft, I'll just reuse the text.


> What I don't know is if these extensions are implemented anywhere yet,
> specifically OpenSSL.  I quick examination of the source, or a query on
> the mailing list would probably tell us.

Feel free to look into that, but I'd expect it'll happen promptly after 
the RFC is published regardless.  So I'm willing to make this dependent on 
implementation in the TLS layer.


-- 
Jeffrey M. Vinocur
jeff at litech.org