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

Jeffrey M. Vinocur jeff at litech.org
Tue Mar 4 14:54:01 PST 2003


On Tue, 4 Mar 2003, Ken Murchison wrote:

> "Jeffrey M. Vinocur" wrote:
> 
> > But it's not, really.  A server can implement STARTTLS using 483 and not
> > support any form of AUTHINFO at all.  Fun, eh?
> 
> I don't follow.  What command other than AUTHINFO would realistically
> require the presence of TLS?

Suppose the server wants to forbid plaintext connections altogether, to 
protect the data (perhaps it's able to authenticate the client by IP or 
some other non-password mechanism)?  Right now it can do so by listening 
on 563 and not 119, but we're discouraging that and therefore need to 
provide an alternative.


> AUTHINFO would block on TLS.  It's going to block anyways
> because IESG won't allow unprotected plaintext mechs.

Well sure, but hopefully this will be done long before the other.


> > Do both the client and server know on which octet normal data resumes
> > after a failed negotiation?
> 
> They should, since TLS is a handshaking protocol.  None of the other
> application protocols have a problem.  
> I guess we could just use 403 or 503 for a failed TLS.

Still, I suppose I should list whatever we decide in the Response Codes 
section.  Russ, thoughts on this?


> Are there any implementations other than INN and Cyrus?  ;)

Hey, you never know.


> > It's sort of a shame that we don't have a chance to send 200 or 201 again,
> 
> Can't the client just do MODE READER?

Hmm, sure.


-- 
Jeffrey M. Vinocur
jeff at litech.org




More information about the ietf-nntp mailing list