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

From: [email-masked]
Date: Fri, 26 Sep 2008 22:25:13 +0200 (CEST)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2008 11:10:42 +0200

>    pre-shared key (PSK). ^^^

OK

>    implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

I suggest to add "[RFC4279]" to end of the sentence so that it is easy
to find the definition.

>    TLS_RSA_WITH_AES_128_CBC_SHA).

Please s/Fro/For and add "[RFC 5246]" as a service to the readers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2008 11:10:42 +0200

OK

/js

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 29 Sep 2008 15:00:37 -0400

Hi,

In syslog WG, we worked with the AD to decide what text was needed
regarding ciphersuite support. We removed ciphersuite text that was
redundant with TLS specs, and simplified ciphersuite support to this:

   TLS typically uses certificates [RFC5280] to authenticate peers.
   Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
   support the mandatory to implement cipher suite, which is
   TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to
   future versions of TLS, in which case the mandatory to implement
   cipher suite for the implemented version MUST be supported.

All the major toolkits also know how to do TLS1.0 and TLS1.1 required
suites, and many suites hve been updated to support the TLS1.2
required suite. If an implmentation is non-compliant to TLS1.2, it
will presumably fallback to a required ciphersuites for the latest
supported TLS version. The language also allows for new requirements
for new TLS versions, with the same expected falFrom [email-masked]  Mon Sep 29 12:00:48 2008
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>
Date: Mon, 29 Sep 2008 15:00:37 -0400
Cc: [email-masked]
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
Sender: [email-masked]

Hi,

In syslog WG, we worked with the AD to decide what text was needed
regarding ciphersuite support. We removed ciphersuite text that was
redundant with TLS specs, and simplified ciphersuite support to this:

   TLS typically uses certificates [RFC5280] to authenticate peers.
   Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
   support the mandatory to implement cipher suite, which is
   TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to
   future versions of TLS, in which case the mandatory to implement
   cipher suite for the implemented version MUST be supported.

All the major toolkits also know how to do TLS1.0 and TLS1.1 required
suites, and many suites hve been updated to support the TLS1.2
required suite. If an implmentation is non-compliant to TLS1.2, it
will presumably fallback to a required ciphersuites for the latest
supported TLS version. The language also allows for new requirements
for new TLS versions, with the same expectlback effect to the
TLS1.2 required suite.

draft-ietf-syslog-transport-tls-14.txt will be out soon.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, September 26, 2008 4:25 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
> 
> Dear Juergen,
> 
> Thank you for your comments. Responses are in-line.
> 

ed fallback effect to the
TLS1.2 required suite.

draft-ietf-syslog-transport-tls-14.txt will be out soon.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, September 26, 2008 4:25 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
> 
> Dear Juergen,
> 
> Thank you for your comments. Responses are in-line.
>

---

From: [email-masked]
Date: Mon, 29 Sep 2008 21:13:06 +0200 (CEST)

Dear David,

>    cipher suite for the implemented version MUST be supported.

Thank you for this better text. I will certainly integrate it entirely.
However, there is still a need to add a simple sentence on the PSK
authentication (the document optionally enable PSK authentication):

Best regards,
Badra

---

From: [email-masked]
Date: Mon, 29 Sep 2008 21:13:06 +0200 (CEST)

Dear David,

Best regards,
Badra

---

From: [email-masked]
Date: Mon, 29 Sep 2008 23:07:16 +0200 (CEST)

Hi,

Here is a tentative to decide what text was needed regarding ciphersuite
support.

4. Cipher Suite Requirements

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

     In the case of the pre-shared key authentication (described in
     Section 3.3), implementations are REQUIRED to support the cipher
     suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279].

Comments?
Best regards,
Badra

>    Implementations MUST From [email-masked]  Mon Sep 29 14:08:22 2008
Date: Mon, 29 Sep 2008 23:07:16 +0200 (CEST)
From: [email-masked]
To: =?utf-8?Q?David=C2_B=C2_Harrington=C2?= <[email-masked]>
Importance: Normal
Cc: =?utf-8?Q?=C2?= <[email-masked]>
Subject: [Netconf] =?utf-8?b?IFJFOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?=
 =?utf-8?q?conf-t__ls-04=2Etxt?=
Sender: [email-masked]

Hi,

Here is a tentative to decide what text was needed regarding ciphersuite
support.

4. Cipher Suite Requirements

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

     In the case of the pre-shared key authentication (described in
     Section 3.3), implementations are REQUIRED to support the cipher
     suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279].

Comments?
Best regards,
Badra

>    Implementationssupport TLS 1.2 [RFC5246] and are REQUIRED to
> for new TLS versions, with the same expected fallback effect to the
> TLS1.2 required suite.
>

 MUST support TLS 1.2 [RFC5246] and are REQUIRED to
> for new TLS versions, with the same expected fallback effect to the
> TLS1.2 required suite.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Sep 2008 23:20:18 +0200

>      suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279].

Fine with me.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Sep 2008 23:20:18 +0200

Fine with me.

/js

---

From: "tom.petch" <[email-masked]>
Date: Tue, 30 Sep 2008 15:33:47 +0200

----- Original Message -----
From: <[email-masked]>
To: "DavidÂ BÂ HarringtonÂ" <[email-masked]>
Cc: "Â" <[email-masked]>
Sent: Monday, September 29, 2008 11:07 PM
Subject: [Netconf] RE:Â Â WGLCÂ forÂ draft-ietf-netconf-t ls-04.txt

>      suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279].

I think that you need more than this, somewhere in the document, giving the
applicability of the two very different suites, when is one appropriate, when
the other.  As it stands, I get the feeling that I am being told that you really
should be using PSK but that someone, perhaps that nasty old security
directorate, has insisted we conform to BCP0061 and so have had to include the
other as well:-)

But as to what that text might look like, I am less clear.

Tom Petch

<snip>

---

From: "tom.petch" <[email-masked]>
Date: Tue, 30 Sep 2008 15:33:47 +0200

----- Original Message -----
From: <[email-masked]>
To: "DavidÂ BÂ HarringtonÂ" <[email-masked]>
Cc: "Â" <[email-masked]>
Sent: Monday, September 29, 2008 11:07 PM
Subject: [Netconf] RE:Â Â WGLCÂ forÂ draft-ietf-netconf-t ls-04.txt

Tom Petch

<snip>

---

From: [email-masked]
Date: Tue, 30 Sep 2008 18:22:49 +0200 (CEST)

> directorate, has insisted we conform to BCP0061 and so have had to include

I think the "applicability" or the benefits of using pre-shared key based
authentication have been explained in the Introduction of [RFC4279]. To
recall of them, would be sufficient to insert the following text at the
end of the first paragraph of Section 3? (The use of PSK is a MAY, not a
SHOULD)

"The benefits of pre-shared symmetric-key vs. public-/private-key pair
based authentication for the key exchange in TLS have been explained in
the Introduction of [RFC4279]".

Best regards
Badra

---

From: [email-masked]
Date: Tue, 30 Sep 2008 18:22:49 +0200 (CEST)

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Sep 2008 19:33:50 +0200

> the Introduction of [RFC4279]".

If you add an explicit pointer to the benefits of PSKs by pointing to
the Introduction of RFC 4279, then I like to request that you also add
an explicit pointer to the applicability statement contained in
section 1.1 of RFC 4279. The text starts as follows:

I assume we have agreement that PSKs following RFC 4279 are on
optional to implement feature and my preference would be to trust
implementors that they go and read RFC 4279 and then decide wether
PSKs are in their interest or not without highlighting any benefits
of drawbacks in the NETCONF transport mapping itself.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Sep 2008 19:33:50 +0200

/js

---

From: [email-masked]
Date: Tue, 30 Sep 2008 19:41:09 +0200 (CEST)

>    alternatives may be more appropriate.

No problem. What about:
    "The application statement and the benefits of using the pre-shared
     key based authentication have been explained in the Introduction of
     [RFC4279]".

Best regards,
Badra

---

From: [email-masked]
Date: Tue, 30 Sep 2008 19:41:09 +0200 (CEST)

No problem. What about:

Best regards,
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Sep 2008 19:54:23 +0200

>      key based authentication have been explained in the Introduction of

Or:

  "For details concerning pre-shared key based authentication see
  [RFC4279]".

Less is more.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Sep 2008 19:54:23 +0200

Or:

Less is more.

/js

---

From: [email-masked]
Date: Tue, 30 Sep 2008 20:14:02 +0200 (CEST)

>   "For details concerning pre-shared key based authentication see

OK. I will insert this sentence at the end of 1st paragraph, Section 3

Thanks.
Best regards
Badra

---

From: [email-masked]
Date: Tue, 30 Sep 2008 20:14:02 +0200 (CEST)

Thanks.
Best regards
Badra