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