Hi all,
Last year, we spoke about a possible refresh of RFC 4642 (TLS with NNTP)
to be consistent with the latest published RFCs about TLS, notably UTA
BCP 195.
I based my work on RFC 7590 (TLS with XMPP).
In case you have any comments about the following document, that is now
in Last Call stage, please tell.
https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-01
I have especially two questions for UTA (Appendix E):
Here are wording proposals, that I shall integrate in the next revision
of the draft. In case you see something wrong, please do not hesitate
to speak up.
1/ Should the following paragraph in Section 2.2.2 of [RFC4642]
remain as-is or should it be modernized with another wording?
(And which one? or is it already done by the reference to
[RFC7525]?)
Quoting [RFC4642]:
Servers MUST be able to understand backwards-compatible TLS Client
Hello messages (provided that client_version is TLS 1.0 or later),
and clients MAY use backwards-compatible Client Hello messages.
Neither clients nor servers are required to actually support Client
Hello messages for anything other than TLS 1.0. However, the TLS
extension for Server Name Indication ("server_name") [TLS-EXT] SHOULD
be implemented by all clients; it also SHOULD be implemented by any
server implementing STARTTLS that is known by multiple names.
(Otherwise, it is not possible for a server with several hostnames to
present the correct certificate to the client.)
The first two sentences are removed. There is no special
requirement for NNTP with regards to TLS Client Hello messages.
Section 7.4.1.2 and Appendix E of [RFC5246] apply.
The last two sentences are removed. Section 3.6 of [RFC7525] apply.
The consequence of the removal of the last two sentences is:
o NNTP implementations and deployments MUST support the Server Name
Indication (SNI) extension defined in Section 3 of [RFC6066],
contrary to Section 2.2.2 of [RFC4642] for which it was only a
SHOULD. All clients and servers known by multiple names MUST
support the SNI extension, in conformance with Section 3.6 of
[RFC7525].
2/ Should the paragraphs in Section 5 of [RFC4642] dealing with how
the client checks the server hostname and the binding between the
identity of servers and the public keys presented be modernized?
(Obsolete them in favour of [RFC6125] for instance? or maybe
[RFC7525] is enough as it also points to [RFC6125])
Quoting [RFC4642]:
During the TLS negotiation, the client MUST check its understanding
of the server hostname against the server's identity as presented in
the server Certificate message, in order to prevent man-in-the-middle
attacks. Matching is performed according to these rules:
[...]
I've seen in private with Peter Saint-Andre, who pointed me to the
recently published RFC 7817 as a source of wording inspiration.
I'll have a look, though I am half-tempted to just keep the current RFC
4642 wording for now. I am under the impression that a separate RFC
like RFC 7817 would be better. (The current wording about certificate
validation is still OK in RFC 4642, so there is currently no urgent need
to update NNTP certificate validation to match RFC 6125, contrary to the
other updates mentioned in the draft about RC4, TLS-level compression
and strict TLS.)
--
Julien ÉLIE
« Ils ont coulé mon entreprise. » (les pirates, dans _Astérix_)
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
