[Netconf] RE: WGLC for draft-ietf-netconf-t ls-04.txt

[[e-mail]]

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.

     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.

     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

> 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 From [e-mail]  Mon Sep 29 14:08:22 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 0BAF73A6AD9;
	Mon, 29 Sep 2008 14:08:22 -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 39CDD3A6A81
	for <[e-mail]>; Mon, 29 Sep 2008 14:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.44
X-Spam-Level: 
X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=0.357, 
	BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3,
	SARE_SUB_ENC_UTF8=0.152]
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 fTB+OT9pfcBD for <[e-mail]>;
	Mon, 29 Sep 2008 14:08:19 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id B39AD3A6A43
	for <[e-mail]>; Mon, 29 Sep 2008 14:08:18 -0700 (PDT)
Received: from www.isima.fr ([e-mail] [193.55.95.79])
	by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TM8LpP761998;
	Mon, 29 Sep 2008 23:08:21 +0100
Received: from 88.164.98.77 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Mon, 29 Sep 2008 23:07:16 +0200 (CEST)
Message-ID: <[e-mail]>
In-Reply-To: <00bb01c92265$a9c7ba90$[e-mail]>
References: <[e-mail]>
	<00bb01c92265$a9c7ba90$[e-mail]>
Date: Mon, 29 Sep 2008 23:07:16 +0200 (CEST)
From: [e-mail]
To: =?utf-8?Q?David=C2_B=C2_Harrington=C2?= <[e-mail]>
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
X-Priority: 3
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
	(sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 23:08:21 +0100 (WEST)
Cc: =?utf-8?Q?=C2?= <[e-mail]>
Subject: [Netconf] =?utf-8?b?IFJFOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?=
 =?utf-8?q?conf-t__ls-04=2Etxt?=
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,

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.

     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.

     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

> 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.
>    Implementationssupport 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 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


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