[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

Ken Murchison ken at oceana.com
Tue Mar 9 12:19:34 PST 2004


Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>The server has complete control over the negotiation.  Its provides a
>>list of options from which the client can choose.  The server should
>>only provide those options that it is willing to accept, and shouldn't
>>have to decide *after* the negotiation is complete whether or not it is
>>happy with the outcome.  As a result, I think the case where TLS
>>negotiation is successful but the server then refuses other commands
>>with 483 (or some other code) is, and should be, nonexistent.  Either
>>TLS succeeds, or it fails, period.  Obviously, if TLS fails, then
>>issuing 483 for subsequent commands makes sense, but the client should
>>already expect this.
> 
> 
> This makes our lives massively easier.  Thank you for the information!
> Given this, I agree that we're worrying too much about this case; the only
> case that we actually have to talk about is the case where TLS negotiation
> fails entirely.

Keep in mind that what I said above is based on my (non exhaustive) 
knowledge of TLS and its use in IMAP and POP3.  I'd like to get 
independent confirmation that the issues brought up in RFC 3207 (and 
Jeff's text) are either overkill or don't apply to NNTP.

That being said, I would definitely design a server so that it only 
advertises options which it is willing to accept.

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



More information about the ietf-nntp mailing list