----- Original Message -----
From: <badra@isima.fr>
To: "tom.petch" <cfinss@dial.pipex.com>
Cc: <badra@isima.fr>; "David Harrington" <dbharrington@comcast.net>
Sent: Wednesday, October 01, 2008 2:56 PM
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt


> >> "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 clFrom netconf-bounces@ietf.org  Wed Oct  1 10:57:57 2008
Return-Path: <netconf-bounces@ietf.org>
X-Original-To: netconf-archive@ietf.org
Delivered-To: ietfarch-netconf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 965173A6859;
	Wed,  1 Oct 2008 10:57:57 -0700 (PDT)
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id F08CD3A681F
	for <netconf@core3.amsl.com>; Wed,  1 Oct 2008 10:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.149, 
	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 eDi4POImp1as for <netconf@core3.amsl.com>;
	Wed,  1 Oct 2008 10:57:56 -0700 (PDT)
Received: from mk-outboundfilter-1.mail.uk.tiscali.com
	(mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37])
	by core3.amsl.com (Postfix) with ESMTP id AC8B93A6405
	for <netconf@ietf.org>; Wed,  1 Oct 2008 10:57:55 -0700 (PDT)
X-Trace: 176470134/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.143.234
X-SBRS: None
X-RemoteIP: 62.188.143.234
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAAdX40g+vI/q/2dsb2JhbACDRziIXapvhnwDbHs
X-IronPort-AV: E=Sophos;i="4.33,344,1220223600"; d="scan'208";a="176470134"
X-IP-Direction: IN
Received: from 1cust234.tnt14.lnd4.gbr.da.uu.net (HELO allison)
	([62.188.143.234])
	by smtp.pipex.tiscali.co.uk with SMTP; 01 Oct 2008 18:56:27 +0100
Message-ID: <001901c923e5$9b2d73e0$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: <badra@isima.fr>
References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com>
	<61043.88.164.98.77.1222722436.squirrel@www.isima.fr>
	<001301c9230c$7ed77940$0601a8c0@allison>
	<54288.88.164.98.77.1222791769.squirrel@www.isima.fr>
	<000c01c923aa$054cc6e0$0601a8c0@allison>
	<55201.88.164.98.77.1222865792.squirrel@www.isima.fr>
Date: Wed, 1 Oct 2008 18:48:01 +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: netconf@ietf.org
Subject: Re: [Netconf]
	=?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?=
	=?utf-8?q?=2Etxt?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:netconf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: netconf-bounces@ietf.org
Errors-To: netconf-bounces@ietf.org

----- Original Message -----
From: <badra@isima.fr>
To: "tom.petch" <cfinss@dial.pipex.com>
Cc: <badra@isima.fr>; "David Harrington" <dbharrington@comcast.net>
Sent: Wednesday, October 01, 2008 2:56 PM
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt


> >> "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 ients 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'?
> >
>
> Maybe I don't understand well your point here; using PSK is optional with
> the document and the only mandatory mode to implement is certificate base
> authentication.
>
> The Jurgen proposal works for you? (inserting the following sentence at
> the end of paragraph 1 of Section 3: "For details concerning pre-shared
> key based authentication see [RFC4279]".)
>

The problem I have is why specify two cipher suites out of the legion that are
available.  One strong one must be present (BCP0061), why specify another,
unless there is a use case, an applicability, where it is likely to be
widespread or a markedly better choice.

My take has always been that TLS, PKI etc works well when the server is large,
powerful, central etc, capable of doing anything that the IETF might suggest;
and clients are workstations equipped with a human operator, able to decide what
to do about certificate error messages ('name does not match' 'date is in the
future' etc).  HTTP fits that well (what a surprise:-), syslog does not (and is
a simplex protocol to boot).  So fingerprints and syslog seem like good
bedfellows.

So with netconf, why mention PSK at all? Fingerprints I would understand from
parallels to syslog, PSK I do not.  And I suspect that the user who goes to
RFC4279 for enlightenment will be disappointed; fine RFC but an explanation of
applicability is not there, IMHO.

Tom Petch

> And what is the reason to add fingerprint to Netconf?
>
> Best regards,
> Badra
>

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


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'?
> >
>
> Maybe I don't understand well your point here; using PSK is optional with
> the document and the only mandatory mode to implement is certificate base
> authentication.
>
> The Jurgen proposal works for you? (inserting the following sentence at
> the end of paragraph 1 of Section 3: "For details concerning pre-shared
> key based authentication see [RFC4279]".)
>

The problem I have is why specify two cipher suites out of the legion that are
available.  One strong one must be present (BCP0061), why specify another,
unless there is a use case, an applicability, where it is likely to be
widespread or a markedly better choice.

My take has always been that TLS, PKI etc works well when the server is large,
powerful, central etc, capable of doing anything that the IETF might suggest;
and clients are workstations equipped with a human operator, able to decide what
to do about certificate error messages ('name does not match' 'date is in the
future' etc).  HTTP fits that well (what a surprise:-), syslog does not (and is
a simplex protocol to boot).  So fingerprints and syslog seem like good
bedfellows.

So with netconf, why mention PSK at all? Fingerprints I would understand from
parallels to syslog, PSK I do not.  And I suspect that the user who goes to
RFC4279 for enlightenment will be disappointed; fine RFC but an explanation of
applicability is not there, IMHO.

Tom Petch

> And what is the reason to add fingerprint to Netconf?
>
> Best regards,
> Badra
>

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf