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

[Ken Murchison]

"Jeffrey M. Vinocur" wrote:
> 
> 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.

Since these are all related to one command, it never even occurred to me
to separate them.

> > - 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?

Hmm, good point.  I would argue that this is an AUTHINFO specific
response code and belongs in the AUTHINFO draft.

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


> > - 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

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.

> negotiation begins immediately).  I haven't actually checked what INN does
> if you use STARTTLS...I believe it does not reissue the banner.

You're right, it doesn't AFAICT.  It follows RFC 2595 and RFC 3207.

> 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.

I understand the point of the note, I guess I'm lobbying to have this
functionality taken care of by TLS.

> 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.

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

Its in the RFC Editor queue: http://www.rfc-editor.org/queue.html

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.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp