Subject: Re: [Syslog] stream transport was draft-ietf-syslog-transport-tls-01.txt

From: "Tom Petch" <[email-masked]>
Date: Fri, 16 Jun 2006 10:12:35 +0200

I think that this document has some way to go.  It has introduced, and woven
together, both TLS and TCP transport, which I think wrong.  Ideally, I think
that we should have two separate documents, one dealing with TLS, the other with
TCP issues; given that both would be short, it is probably sensible to have only
the one, but I still see the need for separation within the document.  After
all, DTLS exists: an outsider could, should, think that syslog is UDP-based,
DTLS provides UDP security so DTLS is the obvious choice, what on earth is this
document talking about?  We need a section on DTLS (if only justifying why it is
not for further consideration).  And, for me, that alone justifies teasing out
the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?.

That said, I do not think that this document adequately covers the TCP issues,
ones that have surfaced on the list before.

TLSoTCP can deliver one syslog message, many syslog messages, part of a syslog
message or a combination thereof - it is in the nature of a stream protocol.
This needs spelling out.

A TCP connection takes time to set up, TLSoTCP longer.  This needs spelling out;
if timely delivery is a concern, then the connection should be established in
advance.

The section on TCP termination is too weak.  If we are recommending a timeout,
then we should recommend a value, even specifying that it should be configurable
over a range.  And if we cannot agree on such values, I do not think we should
be specifying a timeout.

TCP perforce introduces flow control.  This will slow down and rate limit
messages; what is the impact of this on the application?

TCP failures can terminate the connection!  Again, this has an impact on the
application with the time taken to become aware that the connection has failed.

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 09, 2006 4:26 PM
Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt

Hi,

A new revision of the syslog/TLS draft is available.
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01
.txt

We need reviewers.
Can we get
1) a person to check the grammar?
2) a person to check the syslog technical parts?
3) a person to check compatibility with the other WG documents?
4) a person to check the TLS technical parts?

We also need general reviews of the document by multiple people.

Thanks,
David Harrington
co-chair, Syslog WG
[email-masked]
_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

__________________________________________a.uu.net [62.188.122.160])
	by galaxy.systems.pipex.net (Postfix) with SMTP id CA339E0006B4;
	Fri, 16 Jun 2006 10:25:06 +0100 (BST)
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Syslog] stream transport was
	draft-ietf-syslog-transport-tls-01.txt
Date: Fri, 16 Jun 2006 10:12:35 +0200
Cc: 
Reply-To: Tom Petch <[email-masked]>

I think that this document has some way to go.  It has introduced, and woven
together, both TLS and TCP transport, which I think wrong.  Ideally, I think
that we should have two separate documents, one dealing with TLS, the other with
TCP issues; given that both would be short, it is probably sensible to have only
the one, but I still see the need for separation within the document.  After
all, DTLS exists: an outsider could, should, think that syslog is UDP-based,
DTLS provides UDP security so DTLS is the obvious choice, what on earth is this
document talking about?  We need a section on DTLS (if only justifying why it is
not for further consideration).  And, for me, that alone justifies teasing out
the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?.

That said, I do not think that this document adequately covers the TCP issues,
ones that have surfaced on the list before.

TLSoTCP can deliver one syslog message, many syslog messages, part of a syslog
message or a combination thereof - it is in the nature of a stream protocol.
This needs spelling out.

A TCP connection takes time to set up, TLSoTCP longer.  This needs spelling out;
if timely delivery is a concern, then the connection should be established in
advance.

The section on TCP termination is too weak.  If we are recommending a timeout,
then we should recommend a value, even specifying that it should be configurable
over a range.  And if we cannot agree on such values, I do not think we should
be specifying a timeout.

TCP perforce introduces flow control.  This will slow down and rate limit
messages; what is the impact of this on the application?

TCP failures can terminate the connection!  Again, this has an impact on the
application with the time taken to become aware that the connection has failed.

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 09, 2006 4:26 PM
Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt

Hi,

A new revision of the syslog/TLS draft is available.
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01
.txt

We need reviewers.
Can we get
1) a person to check the grammar?
2) a person to check the syslog technical parts?
3) a person to check compatibility with the other WG documents?
4) a person to check the TLS technical parts?

We also need general reviews of the document by multiple people.

Thanks,
David Harrington
co-chair, Syslog WG
[email-masked]
_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

_____
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 19 Jun 2006 11:27:01 +0200

Reading this I-D (-02 actually), I seem to recognise wording from the TLS RFC
but, I think, not enough to make clear what TLS does and does not offer.  The
I-D talks of strong mutual authentication, compression and encryption but fails
to mention ciphersuites.  Compression is negotiated per se but key exchange (eg
RSA), authentication (eg SHA) and encryption (eg 3DES-EDE) come as a package, a
predefined list of ciphersuites, and if the combination you want is not
predefined, tough (go write your own RFC).  Equally, NULL, NULL, NULL is a valid
TLS ciphersuite, but rather weak on security.

This may be all very familiar but I think it needs spelling out because one
ciphersuite must be REQUIRED to ensure interoperability.  As the I-D stands,
this will be
TLS_RSA_WITH_3DES_EDE_CBC_SHA
which, as the name suggests, calls for a certificate with RSA public key valid
for encryption, 3DES_EDE and SHA.

Earlier, I queried the support for TLS and was pointed at the 220,000 hits on
Google; my follow up question is, what is the commonest ciphersuite in use,
amongst those secure enough to satisfy the IESG?  (DES40_CBC will not do:-)

Is this default what we want?  SHA is fine for me.  Certificates are not present
in all ciphersuites; the I-D takes them for granted but fails to specify which.
Is encryption always wanted? As I have said before, it is an irrelevance for the
environments I am familiar with (although I accept it is a requirement for
others) but do we insist it is always present?

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 09, 2006 4:26 PM
Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt

Hi,

We need reviewers.
Can we get

Thanks,
David Harrington
co-chair, Syslog WG
[email-masked]

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 20 Jun 2006 09:46:44 +0800

Thread-index: AcaTi5xhytEuUEfZQZCKwibPxvjz7gAeKT8A

Section 9 of RFC4346 says:
   "In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA."

It is OK to mandate a ciphersuite for application profile(Syslog/TLS). But,
note that the ciphersuite you suggested is the same one mandated in RFC4346.
Maybe it is not necessary to mandate twice. RFC2818(HTTPS) does not specify
ciphersuite. 

I believe TLS_RSA_WITH_3DES_EDE_CBC_SHA is one of the commonest ciphersuite
and satisfies IESG, RFC4346 is relatively new and comes after
Bellovin-Rescorla analysis. 

Server certificate is a MUST for non-anonymous key-exchange in section 7.4.2
of RFC4346, in which the relationship between certificate and ciphersuite is
defined. This may the same case to whether ciphersuite should be specified
in application profile. 

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]] 
> Sent: Monday, June 19, 2006 5:27 PM
> To: [email-masked]
> Subject: Re: [Syslog] ciphersuites was 
> Reading this I-D (-02 actually), I seem to recognise wording 
> from the TLS RFC but, I think, not enough to make clear what 
> TLS does and does not offer.  The I-D talks of strong mutual 
> authentication, compression and encryption but fails to 
> mention ciphersuites.  Compression is negotiated per se but 
> key exchange (eg RSA), authentication (eg SHA) and encryption 
> (eg 3DES-EDE) come as a package, a predefined list of 
> ciphersuites, and if the combination you want is not 
> predefined, tough (go write your own RFC).  Equally, NULL, 
> NULL, NULL is a valid TLS ciphersuite, but rather weak on security.
> 
> This may be all very familiar but I think it needs spelling 
> out because one ciphersuite must be REQUIRED to ensure 
> interoperability.  As the I-D stands, this will be 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA which, as the name suggests, 
> calls for a certificate with RSA public key valid for 
> encryption, 3DES_EDE and SHA.
> 
> Earlier, I queried the support for TLS and was pointed at the 
> 220,000 hits on Google; my follow up question is, what is the 
> commonest ciphersuite in use, amongst those secure enough to 
> satisfy the IESG?  (DES40_CBC will not do:-)
> 
> Is this default what we want?  SHA is fine for me.  
> Certificates are not present in all ciphersuites; the I-D 
> takes them for granted but fails to specify which.
> Is encryption always wanted? As I have said before, it is an 
> irrelevance for the environments I am familiar with (although 
> I accept it is a requirement for

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 20 Jun 2006 10:22:36 +0800

I believe when people talks about TLS, he is talking about RFC4346 or
RFC2246 rather than DTLS. TLS itself is over TCP, so it is not illogical to
include something about TCP. 

Yes, maybe it is favorable to have Syslog over TCP and Syslog over DTLS for
Syslog working group. But, there will be several transport documents for the
working group:
1, Syslog over UDP, already there and favorable for implementers
2, Syslog over TCP, what is the benefit? 
3, Syslog over TLS
4, Syslog over DTLS, I reckon implementer would like it, but does IESG
satisfy to this transport? 
With so many transport, implementer will be puzzled. Which is recommended by
the working group? The current ones are option 1 and 3.

> Sent: Friday, June 16, 2006 4:13 PM
> To: [email-masked]
> Subject: Re: [Syslog] stream transport 
> wasdraft-ietf-syslog-transport-tls-01.txt
> 
> I think that this document has some way to go.  It has 
> introduced, and woven together, both TLS and TCP transport, 
> which I think wrong.  Ideally, I think that we should have 
> two separate documents, one dealing with TLS, the other with 
> TCP issues; given that both would be short, it is probably 
> sensible to have only the one, but I still see the need for 
> separation within the document.  After all, DTLS exists: an 
> outsider could, should, think that syslog is UDP-based, DTLS 
> provides UDP security so DTLS is the obvious choice, what on 
> earth is this document talking about?  We need a section on 
> DTLS (if only justifying why it is not for further 
> consideration).  And, for me, that alone justifies teasing 
> out the TLS issues from the TCP issues; is FRAME-LEN needed 
> over DTLS?.
> 
> That said, I do not think that this document adequately 
> covers the TCP issues, ones that have surfaced on the list before.
> 
> TLSoTCP can deliver one syslog message, many syslog messages, 
> part of a syslog message or a combination thereof - it is in 
> the nature of a stream protocol.
> This needs spelling out.
> 
> A TCP connection takes time to set up, TLSoTCP longer.  This 
> needs spelling out; if timely delivery is a concern, then the 
> connection should be established in advance.
> 
> The section on TCP termination is too weak.  If we are 
> recommending a timeout, then we should recommend a value, 
> even specifying that it should be configurable over a range.  
> And if we cannot agree on such values, I do not think we 
> should be specifying a timeout.
> 
> TCP perforce introduces flow control.  This will slow down 
> and rate limit messages; what is the impact of this on the 
> application?
> 
> TCP failures can terminate the connection!  Again, this has 
> an impact on the application with the time taken to become 
> aware that the connection has failed.
> 
> Tom Petch
>

---

From: Darren J Moffat <[email-masked]>
Date: Tue, 20 Jun 2006 09:51:50 +0100

> the working group? The current ones are option 1 and 3.

Or what about syslog using GSSAPI since that would allow Kerberos or a 
DTLS based GSSAPI mechanism.

-- 
Darren J Moffat

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 20 Jun 2006 12:48:11 +0200

Miao,

the idea of describing syslog over tcp is not to use this as an actual
transport, but to provide this as an interim for other stream transport,
e.g. for use by ssh. The more I think about it, the more logical it
sounds to define how syslog framing works over a stream (not necessarily
tcp). Then, other transports can build on this. As a software engineer,
this is also like I would use layers in my application. So it sounds
quite natural and extensibel.

A current practical good reason for this is the patent claim. An
interim-layer enables us to drop TLS with relative ease if we decide to
do so. 

I've begun to put together some thoughts on stream framing.

Rainer

> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 4:23 AM
> To: 'Tom Petch'
> Cc: [email-masked]
> Subject: RE: [Syslog] stream 
> transportwasdraft-ietf-syslog-transport-tls-01.txt
>

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 20 Jun 2006 14:43:01 +0200

I wonder if others share my concern about the lack of robustness in the way in
which datagrams are delineated in the stream protocol (a TCP rather than a TLS
issue).

The system works as long as
 - the frame length is encoded perfectly
 - the frame length is decoded perfectly
 - no bytes are inserted or removed in error
which is doubtless true in some networks, but I would prefer not to rely on it.

So, when an error occurs, can the Collector/Relay detect it?  Can the
Collector/Relay recover synch?  If not, what does the Collector/Relay do?

There is very little redundancy in the definition of frame length, and syslog
messages have very little structure to help the application, so I think that
this is an issue we should address.

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 09, 2006 4:26 PM
Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt

Hi,

We need reviewers.
Can we get

Thanks,
David Harrington
co-chair, Syslog WG
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Wed, 21 Jun 2006 13:52:51 -0400

Hi,

[Posting as a contributor]
 
Let me tell you that in ISMS we have written an equivalent abstraction
layer. 

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-tmsm
-02.txt discusses how to handle generic session-based security rather
than datagram-based security, transport connection reuse, and other
issues that came up because we now use a streaming protocol. Then we
wrote a protocol-specific proposal in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-isms-secs
hell-03.txt. This separation into an abstract and protocol-specific
layers has been a large task, partly because it is difficult to
eliminate unnecessary repetition between documents, it is difficult to
keep the two documents in sync on terminology, and so on (and I'm the
author for both drafts). 

Having also authored RFC3411 which defines an abstracted modular
architecture for SNMP frameworks, I can also tell you that going in
that direction can end up constraining future development a great
deal. The SMIng WG and the EOS WG suffered a great deal from having to
try to remain compatible with the RFC3411 abstractions.

I am a believer in specifying architectures or frameworks to guide
modular development, but they also need to be taken with a grain of
salt. That is much easier to do in a product development environment
than it is in a standards development environment, so caveat emptor
(and whatever latin phrase suits this best).

I worked for years at Cabletron helping to develop internal standards
for software OS-portability. There was a wonderful quote from somebody
who led the industry effort to standardize some portion of X-Windows
or Xmake. I don't remember the quote, the technology, or who said it,
but I remember the gist of it - Do not try to abstract the concepts
from one instance or implementation of a technology; there should
always be at least two to draw from, and preferably more.

I think that trying to develop an abstraction layer at this point
would be a distraction. I think that this WG has a history of being
easily distracted. As a contributor, I think we should not deal with
an abstraction layer at this time. If the goal is to make it easy to
develop an alternative proposal to TLS, I suggest that using
cut-and-paste techniques to take text from the current syslog/tls
draft (for the threat model discussions) and the current netconf/ssh
draft (for layering over ssh) would be far more efficient than
starting a new document and abstracting the concepts.

My $.02 as a contributor,

David Harrington
[email-masked] 
[email-masked]
[email-masked]
 
> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 6:48 AM
> To: Miao Fuyou; Tom Petch
> Cc: [email-masked]