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

["David B Harrington" <[e-mail]>]

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 [e-mail]  Mon Sep 29 12:00:48 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 86A533A6B66;
	Mon, 29 Sep 2008 12:00:48 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 838D83A6B66
	for <[e-mail]>; Mon, 29 Sep 2008 12:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id rQYfRCnqpFP7 for <[e-mail]>;
	Mon, 29 Sep 2008 12:00:46 -0700 (PDT)
Received: from QMTA09.emeryville.ca.mail.comcast.net
	(qmta09.emeryville.ca.mail.comcast.net [76.96.30.96])
	by core3.amsl.com (Postfix) with ESMTP id 36C7428C127
	for <[e-mail]>; Mon, 29 Sep 2008 12:00:43 -0700 (PDT)
Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51])
	by QMTA09.emeryville.ca.mail.comcast.net with comcast
	id LiUp1a00D16AWCUA9j0f33; Mon, 29 Sep 2008 19:00:39 +0000
Received: from Harrington73653 ([24.128.66.199])
	by OMTA06.emeryville.ca.mail.comcast.net with comcast
	id Lj0d1a00C4HwxpC8Sj0e7a; Mon, 29 Sep 2008 19:00:39 +0000
X-Authority-Analysis: v=1.0 c=1 a=NK_fnipnCRsA:10 a=bH-OIGKTXmwA:10
	a=48vgC7mUAAAA:8 a=-rfTg5z2wFw-5FXC_EwA:9 a=lWFTstjybw6zWNkJIB4A:7
	a=_0l0SF-wvBmQ9uUo5PxkXsiOA1YA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10
	a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10
From: "David B Harrington" <[e-mail]>
To: <[e-mail]>,
	<[e-mail]>
References: <[e-mail]>
Date: Mon, 29 Sep 2008 15:00:37 -0400
Message-ID: <00bb01c92265$a9c7ba90$[e-mail]>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <[e-mail]>
Thread-Index: AckgFhy4+T7oOvKsR8mFow0ayzn08QCTihgA
Cc: [e-mail]
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

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
[e-mail]
[e-mail]
[e-mail]


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Friday, September 26, 2008 4:25 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
> 
> 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
> 

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


ed fallback effect to the
TLS1.2 required suite.

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

David Harrington
[e-mail]
[e-mail]
[e-mail]


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Friday, September 26, 2008 4:25 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
> 
> 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
> 

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