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. There were
two things to do:
- define a new compression facility because TLS 1.3 no longer permits to
compress data (and NNTP was relying on TLS to get data compression, as
mentioned in the abstract of RFC 4642);
- toilet all obsolete TLS-related stuff, in discrepancy with latest RFCs
and UTA BCP 195.
For your information, the result of the first part (a new NNTP COMPRESS
command, inspired from the IMAP COMPRESS command defined in RFC 4978) is
here:
https://tools.ietf.org/html/draft-murchison-nntp-compress-05
I believe the second part is the one that would most interest this WG.
I based my work on RFC 7590 (TLS with XMPP).
I already received a few comments on -00 from 3 persons (Michael
Baeuerle, Richard Kettlewell, and Chris Newman). I have taken them into
account for -01:
https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-01
Do you have any remarks about that proposal?
Is there a chance that UTA takes it as a WG item? (Anyway, even if the
draft remains an independant submission, I would be happy to hear
comments from the WG.)
Especially, I still see a few issues to address:
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.)
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:
- The client MUST use the server hostname it used to open the
connection (or the hostname specified in TLS "server_name"
extension [TLS-EXT]) as the value to compare against the server
name as expressed in the server certificate. The client MUST NOT
use any form of the server hostname derived from an insecure
remote source (e.g., insecure DNS lookup). CNAME canonicalization
is not done.
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
- Matching is case-insensitive.
- A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc., but would not match
example.com.
- If the certificate contains multiple names (e.g., more than one
dNSName field), then a match with any one of the fields is
considered acceptable.
If the match fails, the client SHOULD either ask for explicit user
confirmation or terminate the connection with a QUIT command and
indicate the server's identity is suspect.
Additionally, clients MUST verify the binding between the identity of
the servers to which they connect and the public keys presented by
those servers. Clients SHOULD implement the algorithm in Section 6
of [PKI-CERT] for general certificate validation, but MAY supplement
that algorithm with other validation methods that achieve equivalent
levels of verification (such as comparing the server certificate
against a local store of already-verified certificates and identity
bindings).
3/ Regarding peering between mode-switching news servers, should
something specific be added? NNTP has port 119, and NNTP over TLS
has port 563. NNSP has port 433 but no dedicated port for TLS.
Shouldn't a port for NNSP over TLS be registered? Otherwise, both
reading and peering are supposed to use port 563, which may be
inconvenient. We could then recommend the use of stunnel with TCP
wrappers, or an equivalent mechanism, listening to that new
separate port for mode-switching news servers that do not natively
support TLS for peering.
Thanks again for your valuable point of view on the draft,
--
Julien ÉLIE
« La terre étant ronde, le kilomètre devrait être rond et non pas
carré. » (Ramón Gomez de La Serna)
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
