Subject: [Syslog] Towards closure of syslog-tls issues

From: Miao Fuyou <[email-masked]>
Date: Mon, 27 Nov 2006 15:28:21 +0800

Hi,

Unfortunately (or fortunately), there are several issues raised after the
chair start shepherding process. As the editor, I would like close the
issues as soon as possible, and get the doucment updated. 

1, Version. The wg seems have concensus on removing version from the
transport mapping this time. If there is a objection, please reply. If no, I
would remove it.

2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I
tend to accept the proposal. Please comment if you have a different idea!

3, Ciphersuite. Tom proposed to specify cipher suite in the transport
document, but I still don't find necessity to do so. I tend to agree to
Rainer's proposal:
http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html

4, ABNF issues. I will change " " format back to %d format.

5, Receiver authentication when confidentiality is concern, from "MUST" to
"must", and probably some more sentences about receiver authentication is
required. 

Please feedback if you have different ideas to the proposals above! Thanks!

Regards,
Miao

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

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 27 Nov 2006 14:05:07 -0800 (PST)

Hi Miao,

> transport mapping this time. If there is a objection, please reply. If no, I

Please remove the version.  We have consensus to do this.  Tom Petch does 
raise an important point that I will bring up to our ADs.  Essentially, 
TLS does not have any mechanism to allow for an indication of the contents 
that it is protecting.  This results in the need for separate ports for 
implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS 
needs a different port from foo.v1/TLS.  Both IPsec and SSH (as examples 
of other secure transports) are able to embed an indication of the payload 
within the transport protocol and reuse their ports.  To that end, even 
the byte-count is a bit of a problem, but we'll live with that.

Remove Section 6.2 as well.

> tend to accept the proposal. Please comment if you have a different idea!

Go ahead and remove that reference.

> http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html

In addition to that
- reference the latest TLS RFC and note that there are updates to that
   which need to be considered
- note that the latest ciphers and their relative strengths may be
   found in BCP86
- note that implementors and deployers should keep aware of current
   literature
(This should be about 3 sentences.)

> 4, ABNF issues. I will change " " format back to %d format.

OK

> "must", and probably some more sentences about receiver authentication is

OK

Please make these changes and submit -05 so we can submit this to the 
IESG.

Thanks,
Chris

---

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

The latest TLS RFC is RFC4346 which is amended by RFC4366, RFC4680 and RFC4681
as rfc-index states; the last does not include RFC4507, which I would.

However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which changes the
PRF (away from MD5) inter alia and calls it TLS v1.2.  IFrom [email-masked] Tue Nov 28 07:23:48 2006
From: "tom.petch" <[email-masked]>
To: "Miao Fuyou" <[email-masked]>,
	"'Rainer Gerhards'" <[email-masked]>, <[email-masked]>
Subject: Re: Ciphersuites Re: [Syslog] Updated Syslog-tls Document
Date: Tue, 28 Nov 2006 12:05:11 +0100
Cc: 
Reply-To: "tom.petch" <[email-masked]>

---- 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

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

WFM

Tom Petch

>
> Thanks,
> Miao
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]]
> > Sent: Friday, November 24, 2006 3:16 PM
> > To: Miao Fuyou; tom.petch; [email-masked]
> > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Miao Fuyou [mailto:[email-masked]]
> > > Sent: Friday, November 24, 2006 4:04 AM
> > > To: 'tom.petch'; Rainer Gerhards; [email-masked]
> > > Subject: RE: Ciphersuites Re: [Syslog] Updated Syslog-tls Document
> > >
> > >
> > > 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,
> > > MO, that I-D is too far
away from completion to be worth waiting for but, in the sentence that notes

"that implementors and deployers should keep aware of current literature"

I would include a reference to include ongoing work in the IETF on TLS.

Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "Miao Fuyou" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 27, 2006 11:05 PM
Subject: Re: [Syslog] Towards closure of syslog-tls issues

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
> > > > >
> > > > > 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.
> > > >
> > > > <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: "tom.petch" <[email-masked]>
Date: Tue, 28 Nov 2006 12:18:19 +0100

However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which changes the
PRF (away from MD5) inter alia and calls it TLS v1.2.  IMO, that I-D is too far
away from completion to be worth waiting for but, in the sentence that notes

Tom Petch

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 28 Nov 2006 13:41:11 +0100

Tom,

> From: tom.petch [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2006 12:18 PM
> To: Chris Lonvick; Miao Fuyou
> Cc: [email-masked]
> Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues
> 
> PRF (away from MD5) inter alia and calls it TLS v1.2.  IMO, that I-D
is
> too far

I am not sure here, but I think any reference to ongoing work will put
the I-D to a hold. The reasoning is that any draft expires and after at
most 6 month there is nothing left that could be referenced. If I am
right with this opinion, I consider it better not to mention any
specific effort. I also think that the text Miao proposed should be
sufficiently enough to alert an implementor (and operator) to watch for
further references.

Just my 2 cts...

Rainer
> > > transport mapping this time. If there is a objection, please
reply.
> If no, I
> > > tend to accept the proposal. Please comment if you have a
different
> idea!
> > > Please feedback if you have different ideas to the proposals
above!
> Thanks!

---

From: "tom.petch" <[email-masked]>
Date: Thu, 30 Nov 2006 10:17:09 +0100

Chris

I agreed (mostly) with the actions in your e-mail but do not see them all
reflected in -05.  See <inline>

Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "Miao Fuyou" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 27, 2006 11:05 PM
Subject: Re: [Syslog] Towards closure of syslog-tls issues
>    which need to be considered

This I see, at least the latest RFC part

> - note that the latest ciphers and their relative strengths may be

This I do not see and would like to

> - note that implementors and deployers should keep aware of current

Likewise, this I do not see and would like to

> (This should be about 3 sentences.)

<snip>

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 30 Nov 2006 09:46:30 -0800 (PST)

Hi Miao,

I agree that these should be in the ID before submission to the IESG. 
Please make these changes for version -06 and submit to the ID Editor. 
Once these are in I will submit to Sam and the IESG.

Go ahead and take care of the other minor nits that are pointed out in the 
shepherding document for -05 as well.

Thanks,
Chris