Hi Viktor,
I would also expect that a given user's choice of NNTP server is also fairly static, and in any case user-agents likely want valid certificates and mandatory TLS (as with IMAP and SUBMIT).
Yep, you're right.
If so, I don't see much of a role for opportunistic TLS in NNTP, in which case, the updated spec can be simplified to say that clients SHOULD know whether TLS is expected of their peer, and if so refuse to proceed unless they obtain an authenticated encrypted channel (per all reasonable UTA TLS BCP guidelines, and with support for the MTI ciphers appropriate for all supported TLS versions). In the server-to-server case, once DANE succeeds or fails to get traction for SMTP and XMPP, one might explore using DANE rather than the public CA "Web PKI". But this is premature at this time. With peering largely static, "Web PKI" works well enough, and clients can if they desire more security restrict which CAs they are willing to accept as issuers of the fixed peer's certificate.
Thanks again for having shared your thoughts. We'll take them into account (if of course we update RFC 4642).
-- Julien ÉLIE « Audaces fortuna iuvat. » (inspiré de Virgile, pour les chauves) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
