Re: [Uta] Fwd: Last Call: <draft-elie-nntp-tls-recommendations-01.txt> (Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)) to Proposed Standard

[Julien ÉLIE <[e-mail]>]

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