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

From: "tom.petch" <[email-masked]>
Date: Wed, 1 Oct 2008 11:40:33 +0200

----- Original Message -----
From: <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; "David Harrington" <[email-masked]>;
<[email-masked]>
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 [email-masked]  Wed Oct  1 03:49:39 2008
From: "tom.petch" <[email-masked]>
To: <[email-masked]>
Date: Wed, 1 Oct 2008 11:40:33 +0200
Cc: [email-masked]
Subject: Re: [Netconf]
	=?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?=
	=?utf-8?q?=2Etxt?=
Reply-To: "tom.petch" <[email-masked]>
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; "David Harrington" <[email-masked]>;
<[email-masked]>
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
[email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: [email-masked]
Date: Wed, 1 Oct 2008 14:56:32 +0200 (CEST)

>    It is also possible to use the SRP (Secure From [email-masked]  Wed Oct  1 05:57:26 2008
Date: Wed, 1 Oct 2008 14:56:32 +0200 (CEST)
From: [email-masked]
To: "=?utf-8?Q?tom.petch=C2?=" <[email-masked]>
Importance: Normal
Cc: =?utf-8?Q?=C2?= <[email-masked]>
Subject: Re: [Netconf]
 =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?=
 =?utf-8?q?=2Etxt?=
Sender: [email-masked]

>    It is also possible to use the SRP (SRemote Password)

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

And what is the reason to add fingerprint to Netconf?

Best regards,
Badra

ecure Remote Password)
> 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]".)

And what is the reason to add fingerprint to Netconf?

Best regards,
Badra

---

From: "tom.petch" <[email-masked]>
Date: Wed, 1 Oct 2008 18:48:01 +0200

----- Original Message -----
From: <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; "David Harrington" <[email-masked]>
Sent: Wednesday, October 01, 2008 2:56 PM
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

> >    number of clFrom [email-masked]  Wed Oct  1 10:57:57 2008
Date: Wed, 1 Oct 2008 18:48:01 +0200

----- Original Message -----
From: <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; "David Harrington" <[email-masked]>
Sent: Wednesday, October 01, 2008 2:56 PM
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

> >    number of clients ients and servers.  Even in such environments, other
> > went down the fingerprint route so what makes netconf different, why is it
> > one of those 'limited set of applications'?
> >
>

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 servers.  Even in such environments, other
> > went down the fingerprint route so what makes netconf different, why is it
> > one of those 'limited set of applications'?
> >
>

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

---

From: [email-masked]
Date: Wed, 1 Oct 2008 20:25:30 +0200 (CEST)

> applicability is not there, IMHO.

OK, so better to remove the PSK based authentication, right?
BTW, we received alike comment from Juergen, I will ask the WG members to
decide whatever to keep ot to remove this authentication mode.

Best regards
Badra

---

From: [email-masked]
Date: Wed, 1 Oct 2008 20:25:30 +0200 (CEST)

Best regards
Badra

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 1 Oct 2008 18:09:26 -0400

> applicability is not there, IMHO.

FYI, Fingerprints were added to syslog because TLS has been declared
the mandatory-to-implement transport, because UDP does not support
congestion control. TLS is not the mandatory-to-implement transport
for Netconf, so specific support of fingerprints is not needed for
Netconf for the reasons it is with syslog.

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 1 Oct 2008 18:09:26 -0400

dbh

---

From: [email-masked]
Date: Wed, 8 Oct 2008 20:52:39 +0200 (CEST)

Dear all,

During the syslog WGLC of syslog-tls, there was a discussion about the use
of a registered or a system port for the initial version of syslog over
TLS.  The consensus was that a dedicated port should be requested.

Regarding "Netconf over TLS" document:

On the one hand, some Netconf WG members recommended reviewing the
discussion in the syslog WG to see whether the compliance requirements for
"Netconf over TLS" are consistent with the syslog-tls proposal, which uses
a registered port.

On the other hand, the Netconf WG already assigned system ports for
NetConf over SSH, SOAP and BEEP and the question is why to don't use a
system port for TLS?

The question for the WG to reach a consensus is: do we need a system port
or just a registered port for "Netconf over TLS"?

Please express you preference on the list for one of these two options by
the WGLC deadline.

As a contributor and author, I'd vote for a registered port.
Best regards,
Badra
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: [email-masked]
Date: Wed, 8 Oct 2008 20:52:39 +0200 (CEST)

Dear all,

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Thu, 09 Oct 2008 09:12:25 +0800

Hi,
could anybody tell me what is the exact difference between system port and registered port.what is the qualification for applications to hire system port or registered port?
If we figure it out, it is easy to conclude 'netconf over TLS' suiable to system port or registered port.

washam

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whosFrom [email-masked]  Wed Oct  8 18:12:06 2008
Date: Thu, 09 Oct 2008 09:12:25 +0800
From: fanhuaxiang 90002624 <[email-masked]>
To: [email-masked]
Priority: normal
Cc: [email-masked]
Subject: Re: [Netconf] system or registered port for Netconf over TLS (was
 WGLC for draft-ietf-netconf-tls-04.txt)
Sender: [email-masked]

Hi,
could anybody tell me what is the exact difference between system port and registered port.what is the qualification for applications to hire system port or registered port?
If we figure it out, it is easy to conclude 'netconf over TLS' suiable to system port or registered port.

washam

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: [email-masked]
Date: Thursday, October 9, 2008 2:54 am
Subject: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.txt)
To: [email-masked]

> of a registered or a system port for the initial version of syslog 
> overTLS.  The consensus was that a dedicated port should be requested.
> 

e address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: [email-masked]
Date: Thursday, October 9, 2008 2:54 am
Subject: [Netconf] system or registered port for Netconf over TLS (was WGLC for draft-ietf-netconf-tls-04.txt)
To: [email-masked]

> of a registered or a system port for the initial version of syslog 
> overTLS.  The consensus was that a dedicated port should be requested.
>

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 09 Oct 2008 10:41:07 +0200

> If we figure it out, it is easy to conclude 'netconf over TLS' suiable to system port or registered port.

See RFC4340 section 19.9
Best regards,
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 09 Oct 2008 10:41:07 +0200

See RFC4340 section 19.9
Best regards,
Badra

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Oct 2008 06:48:09 -0400

Hi,

you really don't need a system port. A registered port should suffice.
And using a system port is likely to cause a DISCUSS by the IESG.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, October 08, 2008 2:53 PM
> To: [email-masked]
> Subject: [Netconf] system or registered port for Netconf over 
> TLS (was WGLC for draft-ietf-netconf-tls-04.txt)
> 
> Dear all,
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Oct 2008 06:48:09 -0400

Hi,

dbh