Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

[[e-mail]]

Dear Juergen,

Thank you for your comments. Responses are in-line…

>> With this mail we want to start a WGLC for the draft NETCONF over
>> TLS, which is proposed to publish as a Proposed Standard RFC.

> I have read <draft-ietf-netconf-tls-04.txt> and here are my comments:

> a) I am wondering about PSK support. RFC 4279 says in the
> applicability statement:
>
>  The ciphersuites defined in this document are intended for a rather
>  limited set of applications, usually involving only a very small
>  number of clients and servers.  Even in such environments, other
>  alternatives may be more appropriate.
>
> With NETMOD deployed on many bridges and routers and some host
> systems in the future, we might have a small number of clients with
> a large number of servers and a key management problem.

> Summary: I think the document has improved quite a bit since its early
> days. I am still not 100% convinced about the PSK support and it being
> required to implement.

Is it sufficient to use the key word "MAY" as following to make optional
the PSK use? Or do you prefer to entirely remove PSK related text? In the
first case:

OLD:

   Section 3.1 describes how the client authenticates the server if
   public key certificates are provided by the server, section 3.2
   describes how the server authenticates the client if public key
   certificates are provided by the client, and section 3.3 describes how
   the client and server mutually authenticate one another using a pre-
   shared key (PSK).

NEW:

   Section 3.1 describes how the client authenticates the server if
   public key certificates are provided by the server, section 3.2
   describes how the server authenticates the client if public key
   certificates are provided by the client, and section 3.3 describes how
   the client and server MAY mutually authenticate one another using a
   pre-shared key (PSK). ^^^

> b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA
>  (please add a reference to RFC 4279 where this cipher suite is
>  defined to help the reader) but does not spell out any other cipher
>  suite requirement, essentially making
>  TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps
>  there needs to be more text about required to implement cipher
>  suites or pointers to "standard" required to implement TLS cipher
>  suites that apply here as well.

Yes, this is true. With TLS, and in the absence of an application profile
standard specifying otherwise, a TLS-compliant application MUST implement
a cipher suite, which varies with the TLS version, i.e.:

TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA
TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Please don't hesitate to propose a better text, here is a tentative:

OLD:

   A compliant implementation of the protocol specified in this document
   MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and
   MAY implement any TLS cipher suite that provides mutual authentication.

NEW:

   A compliant implementation of the protocol specified in this document
   MAY implement any TLS cipher suite that provides mutual authentication.

   For authentication based on PSKs, a compliant implementation MUST
   implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

   Fro authentication based on public key certificates, a compliant
   implementation MUST implement the 'mandatory cipher suite' specified by
   each TLS version (e.g.  with TLS 1.2, the mandotary cipher suite is
   TLS_RSA_WITH_AES_128_CBC_SHA).

> c) I suggest to remove "simple" from the text in the introduction.

OK.

> d) What does "highly recommended" mean in terms of IETF terminology?
>  Is this the same as RECOMMENDED? I suggest to stick to the well
>  defined and understood IETF terminology.

OK.

Best regards,
Badra
_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf