Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Jan 2007 18:22:34 -0500

Hi, folks.  I had no comments on the UDP draft or the main protocol
draft so I have forwarded them to IETF last call.

I do have some concerns with the TLS draft.

First, I think the idea of generic certificates will not meet with
consensus of the security community.  It may be OK to use the same
Subject name for all cable modems from a given vendor, but reuse of
private keys is not something we should recommend in an IETF standard.

In general, preferring dnsname subjectAlternativeName to CN in the
subject field seems preferable.  Why does this specification use cn
rather than either always using dnsname or using a procedure similar
to that in RFC 2818.

The text seems confused about what authentication is required when.
Section 5.1 implies that authentication of receivers is optional but
the text requires it.

Are senders and relays required to have a certificate and to use that
certificate?

--Sam

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

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 31 Jan 2007 12:50:15 +0800

Hi Sam, 

Thanks for the review! My response is inline. 

Regards,
Miao

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 7:23 AM
> To: [email-masked]
> Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls
> 
> 
> 
> Hi, folks.  I had no comments on the UDP draft or the main 
> protocol draft so I have forwarded them to IETF last call.
> 
> First, I think the idea of generic certificates will not meet 
> with consensus of the security community.  It may be OK to 
> use the same Subject name for all cable modems from a given 
> vendor, but reuse of private keys is not something we should 
> recommend in an IETF standard.
> 

The working group discussed the issue of generic certificate, and one
paragraph is included in security consideration to remind the risk of using
generic certificate. Syslog client may be implemented on mass device, such
as set top box, cable modems. In such case, provisioning unique certificate
(basically keys) is a huge cost for the operator, and the generic
certificate is preferred by operator. That is why it is introduced into this
document. 

> 
> In general, preferring dnsname subjectAlternativeName to CN 
> in the subject field seems preferable.  Why does this 
> specification use cn rather than either always using dnsname 
> or using a procedure similar to that in RFC 2818.
> 

I checked rfc3280, dNSName subjectAltName is preferrable to common name.
Thanks for correcting it! 

> Section 5.1 implies that authentication of receivers is 
> optional but the text requires it.
> 

Yes, authentication of receiver is optional. Probably one more sentence in
section 4.2 is required to spell out it explicitly. 

> Are senders and relays required to have a certificate and to 
> use that certificate?
> 

It is not required, but it is preferrable for some deployment where
malicious senders may send lots of messages to overwhelm the receiver.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 31 Jan 2007 04:36:32 -0500

I'll get back to you on the generic certificates issue.  For now, I
recommend you read RFC 4107.  Also note that each device needs a
unique MAC address so the manufacturing process tends to have a step
for making a device unique.

So, it sounds like all forms of authentication are optional in this
spec.

You need a clear table describing what attacks are protected against
given each authentication choice.

Wording that table so that man-in-the-middle issues are dealt with
correctly and it is still informative will be tricky.

--Sam

---

From: "tom.petch" <[email-masked]>
Date: Wed, 31 Jan 2007 18:53:09 +0100

<inline>

Tom Petch

----- Original Message -----
From: "Miao Fuyou" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 31, 2007 5:50 AM
Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls

> > I do have some concerns with the TLS draft.
<snip>
> malicious senders may send lots of messages to overwhelm the receiver.
Sam

I have a slightly different view.  To quote the I-D, where it says
"The sender/relay should initiate a connection to the receiver"
I take that as the sender initiates a connection to the receiver if no relay is
present or to the relay (when present), the relay (when present) initiates the
connection to the receiver (collector).  Relay and receiver become TLS Servers
and insofar as TLS Servers have certificates, the relay will have one!

When the next paragraph says
"When a sender/ relay authenticates a receiver it MUST validate the certificate"
I take that to mean that the sender authenticates the receiver if no relay is
present or the sender authenticates the relay (when present) and the relay
authenticates the receiver.

relay and sender are TLS clients.

I appreciate that this is hop by hop security and not ideal end to end security.

Tom Petch