Subject: [Syslog] Updated Syslog-tls Document

From: Miao Fuyou <[email-masked]>
Date: Wed, 22 Nov 2006 09:12:38 +0800

Hi,

There are two major changes since last update.
1, Section 3 is removed. It is an introductory text on TLS, and is neccesary
because TLS is already a normative reference. 
2, Updated the section 4.3.2 (original 5.3.2), removed the text about TLS
layer alert to signal a syslog-transport event

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Nov 2006 09:08:45 +0100

> layer alert to signal a syslog-transport event

I questioned the need for a version number for the TLS transport in
private conversation and now I bring this up again here. I believe we
should agree on a single solution scheme and not introduce any options
here since signalling of a version mismatch is difficult in a fire and
forget situation. The current text says:

>    If a receiver does not support the version in the messages it
>    received, it MAY just save the APPLICATION-DATA in local storage or
>    send a close_notify to signal the closure of the connection.  If a
>    sender/relay finds connections are closed just after successful TLS
>    handshake for three times with same transport mapping version, it
>    SHOULD not connect the receiver again with the same transport mapping
>    version.

This does not at all sound very convincing to me (and I assume what
the author wanted to say is not well said because I believe the
trigger for not trying again would be a close after sending the first
syslog message and not after the successful TLS handshake). Is there
not a potential attack possible here by successfully "killing" a TCP
connection three times in a row?

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 22 Nov 2006 10:12:05 +0100

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, November 22, 2006 9:09 AM
> To: Miao Fuyou
> Cc: [email-masked]
> Subject: Re: [Syslog] Updated Syslog-tls Document
> 
> private conversation and now I bring this up again here. 

Was that private? I thought it was on-list. Anyhow... I concur with your
initial recommendation of removing the version number from the transport
header. The point at that time was that a version in transport specs is
unusual. If there is need to revise a transport header, a new port is
assigend. Sure, ports are a scarce ressource, but how likely is an
incompatible change to the transport header?

> I believe we
> syslog message and not after the successful TLS handshake). 

I, too, assume this was meant...

> Is there

... and I am not happy with it either. There may be different reasons
for tearing down the session, especially in a troubleshooting scenario.
We should keep in mind that one important application for syslog is
troubleshooting failing networks, which increases the likelyhood of
unexpected session terminations.

I object the ultimate "non-delivery" SHOULD. If we use this clause, we
should at least recommend a retry after a specified period.

But my suggestion is to remove the version as well as this text.

Rainer

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 22 Nov 2006 17:39:54 +0800

> Was that private? I thought it was on-list. Anyhow... I 

The public messege can be found at:
http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html

It seems there was a rough concensus that the version number was welcomed to
save port resource when we discussed this issue on the mailing list. That is
the reason why a version number is there. 

> I, too, assume this was meant...

Yeah, this sentence should be improved if version number is kept there. 

> But my suggestion is to remove the version as well as this text.

So do I now...

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 22 Nov 2006 11:12:09 +0100

Hi Miao,

thanks for the update. I have gone through the draft again and found
some, mostly minor, issue. I have listed them below:

-------------------------------------
3.0
==
  The security service is also applicable to BSD Syslog defined in
   RFC3164 [7].  But, it is not ensured that the protocol specification
   defined in this document is applicable to BSD Syslog.
==

Do we really intend to support RFC 3164-style syslog (read: nothing
known about the message format) over this transport? If so, the
consequence is that implementations of -transport-tls must check for
3164 format and eventually be able to handle it.

I suggest removing these two sentence, as it looks we encourage that
case. If they stay, we should clearly state that a receiver is NOT
REQUIRED to implement this.

-------------------------------------
Section 4.3, inside the ABNF:

>    SP = " "

I think this is problematic in respect to 2.4 of RFC 4234. I suggest
replacing by

SP = %d32

-------------------------------------
5.1

==
   When confidentiality is a concern, a sender/relay MUST authenticate
   the receiver to make sure it is talking to the right peer.
==

I do not find the MUST is appropriate here: "when confidentiality is a
concern" is not a hard fact. What does it mean? When MUST I implement
authentication. Is my Implementation not compliant to this doc if I have
the wrong understanding of "when confidentiality is a concern". Or MUST
I always implement it, because confidentiality is probably very often a
concern?

I think this is a operator-issue not to be dealt with in the protocol. I
suggest dropping this sentence or at last spell MUST in lower case.

-------------------------------------
5.2
Isn't that a security consideration (and belongs to that secition)?

-------------------------------------
6.2
IANA registry names must be suggested (of course this comment is
irrelevant if we drop VERSION).

-------------------------------------
Consistent Spelling
Both version and VERSION is used for the respectively-named field. I
suggest to resort to a single spelling. This also removes some
ambiguities if the version field or the concept of a version is meant in
some parts of the text. I suggest using VERSION consistently for the
respective field.

-------------------------------------
"Security Considerations" is missing
I wonder I didn't spot this earlier. IMHO any document must have a
"Security Considerations" section. Of course, the whole document talks
about security, but does that obsolete the section showing the
weaknesses of the protocol?

For example, I have at least three candiates to be included:

- Problems in relay scenario
A relay may receive data via traditional syslog and forward it via a
tls-encrypted channel to its next destination. In this case, the channel
to the next hop is secured, but the trust level of the message is
considerably lower.

- there is no rule that a sender must use the same host name inside the
-protocol HOSTNAME field as it uses in the certificate's common name. I
think that has some security implications.

- cipher suites and such are left to the operator. We should indicate
the (serious) consequences of this selection

---------------------------------------------
One note on the cipher suites:
I know there has been some discussion previously, but I wasn't able to
find the post in question in the archive. Probably you can help me out.

Question: how do we guarantee a minimum interoperability of
implementations of this document if we do not specify any cipher suite?

---------------------------------------------

Rainer

> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Wednesday, November 22, 2006 2:13 AM
> To: [email-masked]
> Subject: [Syslog] Updated Syslog-tls Document
> 
> Hi,
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 22 Nov 2006 11:15:32 +0100

> Sent: Wednesday, November 22, 2006 10:40 AM
> To: Rainer Gerhards; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Syslog] Updated Syslog-tls Document
> 
> 

Agreed, I am guilty of not saying "I agree" on the mailing list. But to
me that did not look like consensus but simply an overlooked message
(there were no responses at all...).

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Wed, 22 Nov 2006 11:37:25 +0100

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: <[email-masked]>; "Miao Fuyou" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 22, 2006 10:12 AM
Subject: RE: [Syslog] Updated Syslog-tls Document

<tp>
Ports may or may not be scarce but they are expensive.  Introduce a new one and
 - anyone with firewall
 - anyone with an application level gateway
 - anyone with a packet filtering router
has to go out and change each and every box to reflect the new assignment, a
slow and costly process.  This cost is often ignored by protocol designers.

As to header change, the elephant in the room is the IPR hanging over this work
which we can do no more about except wait to see what materialises; it could
result in a change.

Tom Petch
<snip>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 22 Nov 2006 14:36:47 +0100

Tom,

> slow and costly process.  This cost is often ignored by 

I agree with you on that. But I think the chance is extremely low that a
considerate change is required. Even then, we could implement some
version checking via special sequences at a later stage. But my root
cause is that I do not expect a change.
> which we can do no more about except wait to see what 

I do not want to get on the slippery slope of the IPR discussion here
again. But: if there will be a valid patent on something as trivial as
using an octet count followed by a space followed by the data, then you
will probably never find anything at all that is unaffected by the IPR.
So I consider the IPR discussion to be actually irrelevant.

Rainer

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 23 Nov 2006 09:23:35 +0800

> > It seems there was a rough concensus that the version number was 
> > welcomed to save port resource when we discussed this issue on the 
> > mailing list. That is the reason why a version number is there.
> 
> Agreed, I am guilty of not saying "I agree" on the mailing 
> list. But to me that did not look like consensus but simply 
> an overlooked message (there were no responses at all...).
> 

Don't feel guilty because you did say "I applaude":-) 
http://www1.ietf.org/mail-archive/web/syslog/current/msg01198.html

I also found support from other active WG members. 

Anyway, let's reconsider the decision and make it right!

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 23 Nov 2006 10:37:39 +0800

Hi, Rainer,

Thanks for your thorough review!

Some responses are inline. 

> Do we really intend to support RFC 3164-style syslog (read: 
> nothing known about the message format) over this transport? 
> If so, the consequence is that implementations of 
> -transport-tls must check for
> I suggest removing these two sentence, as it looks we 
> encourage that case. If they stay, we should clearly state 
> that a receiver is NOT REQUIRED to implement this.
> 

Agreed. More comments from WG is welcome!

> I think this is problematic in respect to 2.4 of RFC 4234. I 
> suggest replacing by
> 
> SP = %d32
> 

I checked the ABNF with:
http://rtg.ietf.org/~fenner/abnf.cgi

It seems the tools suggest to use " " rather than %d32. I checked RFC4234,
it says that it permits the specification of literal text strings directly,
enclosed in quotation-marks. 

I will changed it back to %d32 to keep it consitent with the syslog
protocol. 

> I do not find the MUST is appropriate here: "when 
> confidentiality is a concern" is not a hard fact. What does 
> it mean? When MUST I implement authentication. Is my 
> Implementation not compliant to this doc if I have the wrong 
> understanding of "when confidentiality is a concern". Or MUST 
> I always implement it, because confidentiality is probably 
> very often a concern?
> 
> I think this is a operator-issue not to be dealt with in the 
> protocol. I suggest dropping this sentence or at last spell 
> MUST in lower case.
> 

Probably lower case. The point is confidentility is meaningless without
authenticaion. 

RFC3552 request the residual risk should be descripted in the security
consideration section. The section is about residual risk of generic
certificate.

> IANA registry names must be suggested (of course this comment 
> is irrelevant if we drop VERSION).
> 
> Both version and VERSION is used for the respectively-named 
> field. I suggest to resort to a single spelling. This also 
> removes some ambiguities if the version field or the concept 
> of a version is meant in some parts of the text. I suggest 
> using VERSION consistently for the respective field.
> 

Agreed.

> I wonder I didn't spot this earlier. IMHO any document must 
> have a "Security Considerations" section. Of course, the 
> whole document talks about security, but does that obsolete 
> the section showing the weaknesses of the protocol?
> 

Section 5 is Security Consideration, but maybe I should add a S to it
(Security Considerations):-) 

> A relay may receive data via traditional syslog and forward 
> it via a tls-encrypted channel to its next destination. In 
> this case, the channel to the next hop is secured, but the 
> trust level of the message is considerably lower.
> 

> - there is no rule that a sender must use the same host name 
> inside the -protocol HOSTNAME field as it uses in the 
> certificate's common name. I think that has some security 
> implications.
> 

TLS transport does not check HOSTNAME in syslog message because transport
must not depend on content of the payload (or else a relay must check the
content of each message). 

> - cipher suites and such are left to the operator. We should 
> indicate the (serious) consequences of this selection
> 
> I know there has been some discussion previously, but I 
> wasn't able to find the post in question in the archive. 
> Probably you can help me out.
> 

Tom and I discussed this issue on the mailing list. TLS protocol has its
mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS specification says
that if application profile(syslog-tls in this case) does not specify a
mandatory cipher suite, TLS mandatory suite will apply. So, no need to
specify one in this specification.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 23 Nov 2006 08:24:07 +0100

Miao, 

> Sent: Thursday, November 23, 2006 2:24 AM
> To: Rainer Gerhards
> Cc: [email-masked]

Yes, I know I did say that at that time. But the new Argument from
Juergen was convincing to me. During the nearly 4 years of -protocol, we
have often revised our view based on new arguments and I think this
good.

> Anyway, let's reconsider the decision and make it right!

Good point. It would be helpful if some other WG members could voice an
opinion. We are on a thight deadline. There are only very few things for
dicsussion in -transport-tls. If we act fast, I am confident Miao will
be able to very quickly create a new revision (if necessary).

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 23 Nov 2006 08:47:34 +0100

Hi Miao,

<inline>

Rainer 

> Sent: Thursday, November 23, 2006 3:38 AM
> To: Rainer Gerhards; [email-masked]

Interesting. I am using http://www.apps.ietf.org/abnf.html. I will also
try the one you used and do an additional verification on -protocol with
it. However, I still find that %d32 is more precise than " " and I also
have the impression that RFC 4234 recommends that form (but I may be
wrong).

Bottom line: I am more happy with %d32 (or %x20 as I think all others
are in hex in the doc).

> Probably lower case. The point is confidentility is 

Well... maybe it is just a wording issue. Are we actually REQUIREING a
sender to authenticate the receiver in all cases? If so, we should state
that. My impression so far is that this is something that is optional
and at the discretion of the sender or the operator configuring it. If
so, we should state that clearly too. As an implementor, I am unsure
what to do if I use the above text as a guideline.

> consideration section. The section is about residual risk of generic
see below...

> (Security Considerations):-) 

(also on 5.2) - I must have been blind. I've gone several time through
the document and always overlooked the title of section 5. I am not sure
if the additional "s" had helped my ignorance ;) So I think you can
disregard my comment.
> content of each message). 

wouldn't it still be useful to put that information into the security
considerations? Would it be useful to add something to the security
considerations of -protocol (on the lines of "if the transport provides
identification of the sender, a receiver MAY / SHOULD verify the
provided HOSTNAME)"?

WG comment appreciated.
> specify one in this specification.

Ahh... that was the message I did not find in the archive. Thanks for
bringing it up again. That obiously solves the interop problem. However,
I am still of the view that we should advise operators to use strong
suites in the security considerations section.

---

From: Miao Fuyou <[email-masked]>
Date: Thu, 23 Nov 2006 18:24:58 +0800

> > Probably lower case. The point is confidentility is meaningless 
> > without authenticaion.
> 
> Well... maybe it is just a wording issue. Are we actually 
> REQUIREING a sender to authenticate the receiver in all 
> cases? If so, we should state that. My impression so far is 
> that this is something that is optional and at the discretion 
> of the sender or the operator configuring it. If so, we 
> should state that clearly too. As an implementor, I am unsure 

It does not define what authentication to use. I will check the text to make
sure it expressed this point. 

> > 
> > TLS transport does not check HOSTNAME in syslog message because 
> > transport must not depend on content of the payload (or 
> else a relay 
> > must check the content of each message).
> 
> wouldn't it still be useful to put that information into the 
> security considerations? Would it be useful to add something 
> to the security considerations of -protocol (on the lines of 
> "if the transport provides identification of the sender, a 
> receiver MAY / SHOULD verify the provided HOSTNAME)"?
> 
> WG comment appreciated.

I am not sure, but my perception is -transport and -protocol should be as
independent to each other as possbile. 

> > Tom and I discussed this issue on the mailing list. TLS 
> protocol has 
> > its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS 
> > specification says that if application profile(syslog-tls in this 
> > case) does not specify a mandatory cipher suite, TLS 
> mandatory suite 
> > will apply. So, no need to specify one in this specification.
> 
> Ahh... that was the message I did not find in the archive. 
> Thanks for bringing it up again. That obiously solves the 
> interop problem. However, I am still of the view that we 
> should advise operators to use strong suites in the security 
> considerations section.
> 

Yes, I think TLS also advises the operator strong suites.

---

From: "tom.petch" <[email-masked]>
Date: Thu, 23 Nov 2006 17:56:15 +0100

<inline>
Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: "Miao Fuyou" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 23, 2006 8:47 AM
Subject: RE: [Syslog] Updated Syslog-tls Document

Hi Miao,

<inline>

Rainer

<snip>
> protocol has its

<tp>

I raised it because I wanted a cipher suite spelt out in the I-D rather then
leaving it as an exercise in ingenuity for the reader to find where it is
specified.  The pro and con of not specifying it in our I-D is that as the views
in the security community change (and some would regard the default as too
weak - eg US government) so the mandatory to implement is changed for us without
us noticing.

Tom Petch

___

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

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 24 Nov 2006 11:03:43 +0800

My observation about ciphersuite:
1, TLS wg can do a better job on ciphersuite selection than a profile
developer. 
2, TLS specification will be updated if the mandatory cipher is too weak to
provide appropriate protection, but profile-specific suite may not be
updated accordingly. 
3, Before TLS mandate a stronger cipher suite, TLS_RSA_WITH_3DES_EDE_CBC_SHA
is strong enough for most syslog application. If a operator want a stronger
cipher suite for highly sensitive syslog application, he still has the
freedom to specify one, mandatory cipher suite is only MUST to implementer
rather than operator. 

So, my view is ciphersuite is not neccessary to be defined in this
specification, and it is not good to specify in this specification. 

Thanks,
Miao
> I raised it because I wanted a cipher suite spelt out in the 
> I-D rather then leaving it as an exercise in ingenuity for 
> the reader to find where it is specified.  The pro and con of 
> not specifying it in our I-D is that as the views in the 
> security community change (and some would regard the default 
> as too weak - eg US government) so the mandatory to implement 
> is changed for us without us noticing.
> 
> Tom Petch
> 
> ___

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 24 Nov 2006 08:15:59 +0100

Tom, Miao,

might it be a compromise to add a sentence to -transport-tls that tells
an implementor to look for mandatory to implement suites inside the TLS
document. Something like

"Minimum Interoperability between different implementations of this
specification is achieved via the mandatory to implement cipher suites
specified in <tls-rfc>."

That would be a reminder that might be helpful.

Rainer

> Sent: Friday, November 24, 2006 4:04 AM
> To: 'tom.petch'; Rainer Gerhards; [email-masked]
> Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document
> 
>

---

From: Miao Fuyou <[email-masked]>
Date: Mon, 27 Nov 2006 14:58:16 +0800

Hi,

It looks good.  I tend to add some sentences like the one Rainer proposed.
Any objection?

Thanks,
Miao

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, November 24, 2006 3:16 PM
> To: Miao Fuyou; tom.petch; [email-masked]
> might it be a compromise to add a sentence to -transport-tls 
> that tells an implementor to look for mandatory to implement 
> suites inside the TLS document. Something like
> 
> "Minimum Interoperability between different implementations 
> of this specification is achieved via the mandatory to 
> implement cipher suites specified in <tls-rfc>."
> 
> > 2, TLS specification will be updated if the mandatory cipher is too 
> > weak to provide appropriate protection, but 
> profile-specific suite may 
> > not be updated accordingly.
> > 3, Before TLS mandate a stronger cipher suite, 
> > TLS_RSA_WITH_3DES_EDE_CBC_SHA is strong enough for most syslog 
> > application. If a operator want a stronger cipher suite for highly 
> > sensitive syslog application, he still has the freedom to 
> specify one, 
> > mandatory cipher suite is only MUST to implementer rather than 
> > operator.
> > 
> > > Thanks for bringing it up again. That obiously solves the interop 
> > > problem. However, I am still of the view that we should advise 
> > > operators to use strong suites in the security considerations 
> > > section.
> > > 
> > > <tp>
> > > 
> > > I raised it because I wanted a cipher suite spelt out in the I-D 
> > > rather then leaving it as an exercise in ingenuity for 
> the reader to 
> > > find where it is specified.  The pro and con of not 
> specifying it in 
> > > our I-D is that as the views in the security community 
> change (and 
> > > some would regard the default as too weak - eg US 
> government) so the 
> > > mandatory to implement is changed for us without us noticing.
> > > 
> > > Tom Petch
> > > 
> > > ___
> > 
> > 
> > 
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Nov 2006 19:26:50 -0500

> Sent: Thursday, November 23, 2006 2:48 AM
> To: Miao Fuyou; [email-masked]

Standards do not typically require an operator to use the technology
in a specific manner; Standards do typically require implementers to
implement in a way so that operators CAN configure the technology in
the preferred (interoperable) manner.

MUST is used when the on-the-wire format/information/etc. must be
interoperable for the protocol to work properly.

I do not like seeing "must" in a document; either it deserves to be a
MUST, i.e. it impacts on-the-wire interoperability, or it is an
implementation/usage decision and we should not mandate it. If you use
a lower case "must", then you'll need to convince me as co-chair that
the usage is justifed before I send it to the IESG.

Dbh

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 28 Nov 2006 10:07:19 +0800

I am changing the sentence to:

"For the deployment where confidentiality is a concern, receiver
authentication is required for sender/relay to make sure it is talking to
the right peer. It is up to the operator to decide whether confidentiality
is a concern for a specific deployment. "

This sentence serves as a tip for deployer rather than something about
on-the-wire protocol. 

Thanks,
Miao

> From: David Harrington [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 8:27 AM
> To: 'Rainer Gerhards'; 'Miao Fuyou'; [email-masked]
> confidentiality 
> > > > is a concern" is not a hard fact. What does it mean? 
> When MUST I 
> > > > implement authentication. Is my Implementation not compliant to 
> > > > this doc if I have the wrong understanding of "when 
> > > > confidentiality is a concern". Or MUST I always implement it, 
> > > > because confidentiality is probably very often a concern?
> > > > 
> > > > protocol. I suggest dropping this sentence or at last 
> spell MUST 
> > > > in lower case.
> > > > 
> > > 
> > sender to authenticate the receiver in all cases? If so, we should 
> > state that. My impression so far is that this is something that is
> optional
> Standards do not typically require an operator to use the 
> technology in a specific manner; Standards do typically 
> require implementers to implement in a way so that operators 
> CAN configure the technology in the preferred (interoperable) manner.
> 
> MUST is used when the on-the-wire format/information/etc. 
> must be interoperable for the protocol to work properly.
> 
> I do not like seeing "must" in a document; either it deserves 
> to be a MUST, i.e. it impacts on-the-wire interoperability, 
> or it is an implementation/usage decision and we should not 
> mandate it. If you use a lower case "must", then you'll need 
> to convince me as co-chair that the usage is justifed before 
> I send it to the IESG.
> 
> Dbh
> 
> 
> 
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 28 Nov 2006 00:45:32 -0500

That wording satisfies me.

dbh 

> Sent: Monday, November 27, 2006 9:07 PM
> To: 'David Harrington'; 'Rainer Gerhards'; [email-masked]

> REQUIREING
> > a
> > > and at the discretion of the sender or the operator 
> configuring it.
> > If

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 28 Nov 2006 10:36:33 +0100

Just for the records: I am also statisfied with this wording.

Rainer

> Sent: Tuesday, November 28, 2006 6:46 AM
> To: 'Miao Fuyou'; Rainer Gerhards; [email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Tue, 28 Nov 2006 12:05:11 +0100

---- Original Message -----
From: "Miao Fuyou" <[email-masked]>
To: "'Rainer Gerhards'" <[email-masked]>; "'tom.petch'"
<[email-masked]>; <[email-masked]>
Sent: Monday, November 27, 2006 7:58 AM
Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document

> It looks good.  I tend to add some sentences like the one Rainer proposed.

WFM

Tom Petch