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

["tom.petch" <[e-mail]>]

----- Original Message -----
From: <[e-mail]>
To: "tom.petch" <[e-mail]>
Cc: <[e-mail]>; "David Harrington" <[e-mail]>;
<[e-mail]>
Sent: Tuesday, September 30, 2008 6:22 PM
Subject: RE: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

> >> 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 From [e-mail]  Wed Oct  1 03:49:39 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 342673A6C2D;
	Wed,  1 Oct 2008 03:49:39 -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 2B5A23A6C2D
	for <[e-mail]>; Wed,  1 Oct 2008 03:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.223
X-Spam-Level: 
X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5
	tests=[AWL=-0.076, BAYES_00=-2.599, 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 wT+Xb6he+qb9 for <[e-mail]>;
	Wed,  1 Oct 2008 03:49:37 -0700 (PDT)
Received: from mk-outboundfilter-6.mail.uk.tiscali.com
	(mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14])
	by core3.amsl.com (Postfix) with ESMTP id 276E93A69FE
	for <[e-mail]>; Wed,  1 Oct 2008 03:49:37 -0700 (PDT)
X-Trace: 32824587/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.166
X-SBRS: None
X-RemoteIP: 213.116.60.166
X-IP-MAIL-FROM: [e-mail]
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au8FAC7z4kjVdDym/2dsb2JhbACDRziDV4UBqhKHBgNsew
X-IronPort-AV: E=Sophos;i="4.33,342,1220223600"; d="scan'208";a="32824587"
X-IP-Direction: IN
Received: from 1cust166.tnt106.lnd4.gbr.da.uu.net (HELO allison)
	([213.116.60.166])
	by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 11:49:56 +0100
Message-ID: <000c01c923aa$054cc6e0$0601a8c0@allison>
From: "tom.petch" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><00bb01c92265$a9c7ba90$[e-mail]>
	<[e-mail]>
	<001301c9230c$7ed77940$0601a8c0@allison>
	<[e-mail]>
Date: Wed, 1 Oct 2008 11:40:33 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: [e-mail]
Subject: Re: [Netconf]
	=?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?=
	=?utf-8?q?=2Etxt?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <[e-mail]>
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]

----- Original Message -----
From: <[e-mail]>
To: "tom.petch" <[e-mail]>
Cc: <[e-mail]>; "David Harrington" <[e-mail]>;
<[e-mail]>
Sent: Tuesday, September 30, 2008 6:22 PM
Subject: RE: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

> >> 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 versioversion 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
> >>
> >
> > 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.
>
> 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]".
>

Weeeellllll I sort of see what you mean. Section 1.1 says

"1.1.  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.

   If the main goal is to avoid Public-Key Infrastructures (PKIs),
   another possibility worth considering is using self-signed
   certificates with public key fingerprints.  Instead of manually
   configuring a shared secret in, for instance, some configuration
   file, a fingerprint (hash) of the other party's public key (or
   certificate) could be placed there instead.

   It is also possible to use the SRP (Secure Remote Password)
   ciphersuites for shared secret authentication [SRP].  SRP was
   designed to be used with passwords, and it incorporates protection
   against dictionary attacks.  However, it is computationally more
   expensive than the PSK ciphersuites in Section 2."

which is all quite negative, not exactly benefits or applicability; and syslog
went down the fingerprint route so what makes netconf different, why is it one
of those 'limited set of applications'?

Tom Petch

> Best regards
> Badra

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


n 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
> >>
> >
> > 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.
>
> 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]".
>

Weeeellllll I sort of see what you mean. Section 1.1 says

"1.1.  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.

   If the main goal is to avoid Public-Key Infrastructures (PKIs),
   another possibility worth considering is using self-signed
   certificates with public key fingerprints.  Instead of manually
   configuring a shared secret in, for instance, some configuration
   file, a fingerprint (hash) of the other party's public key (or
   certificate) could be placed there instead.

   It is also possible to use the SRP (Secure Remote Password)
   ciphersuites for shared secret authentication [SRP].  SRP was
   designed to be used with passwords, and it incorporates protection
   against dictionary attacks.  However, it is computationally more
   expensive than the PSK ciphersuites in Section 2."

which is all quite negative, not exactly benefits or applicability; and syslog
went down the fingerprint route so what makes netconf different, why is it one
of those 'limited set of applications'?

Tom Petch

> Best regards
> Badra

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