Subject: RE: [Syslog] transport-tls-11 review

From: Miao Fuyou <[email-masked]>
Date: Wed, 09 Jan 2008 15:00:45 -0800

Thanks for your comments! Response inline. 

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 9:13 AM
> To: Miao Fuyou; 'Rainer Gerhards'; [email-masked]
> Subject: Re: [Syslog] transport-tls-11 review
> 
> <snip>
> > >
> > > ===
> > > The server MUST be implemented to support certificate and 
> certificate
> > >    generation,
> > > ===
> > >
> > > I do not think it is a MUST that a server must contain code to 
> > > generate certificates. This should be left to the implementation. 
> > > There is already the requirement to use certificates, so 
> IMHO it is 
> > > not the business of an IETF document to specify how they are 
> > > provided. For example, I would provide a helper app with 
> my syslog 
> > > implementations, but not include it in the core app - it doesn't 
> > > belong there.
> > >
> >
> > Need more opinion from the working group.
> >
> 
> I agree with Rainer

OK, to be updated in new revision.

> 
> And I see some idiosynchratic wordings that MIGHT be changed.
> 
> 2.  Security Requirements for Syslog
> 
>    syslog messages may pass several hops
> ** not really pass, suggest transit
> 
>    It is recommended to use dNSName in the certificate rather than any
>    other type subjectAltName for certificate verification, such as
>    ipAddress.
> **suggest iPAddress (ie PKI not SNMP)

Ok, thanks!

> 
> 4.2.2.  Client Identity
> 
>    If a server authenticates a client and the client presents a
>    certificate to the server, the server MUST validate the 
> certificate.
>    Validation includes constructing a certificate path to one of the
>    configured trust anchors and validating that path.  
> However, identity
>    check is not required even if subjectAltName is presented in the
>    certificate.
> **I do not understand how failing to check the identity 
> provides protection against Masquerade, as we claim in s.2
> 
>    SubjectAltName is not necessarily unique for different
>    certificates.
> ** suggest The subjectAltName

OK, thanks!

> 
> 5.1.  Authentication and Certificates
> 
>   Mutual authentication means the TLS client and server are
>    provisioned with necessary trust roots
> 
> **suggest trust anchors as in the next paragraph

OK, thanks!

> 
> .  If a server does not
>    have a certificate and key/pair configured **unclear what 
> the solidus is doing - '/' usually means either/or

Typo, should be key pair.

> 
>    The server MUST be implemented to support certificate and 
> certificate
>    generation, and certificate validation MUST be implemented for all
>    clients.  The Syslog client SHOULD be implementated to 
> support **implemented
>    certificate and certificate generation, and certificate validation
>    SHOULD be inplemented for Syslog server.
> 
> **These both read oddly to me - what is the support for certificate
> (certificates?) as distinct from support for certificate 
> generation and certificate validation?  If I support 
> certificate (without qualification), then I expect that to 
> convey support for every aspect thereof so the validation and 
> generation is redundant but, as I agreed with Rainer above, I 
> think that generation should not be a MUST.

There are two way for a server to have a certificate: be configured with
one, or generate one by itself. The "support certificate" is actually to
cover the first case. I agree that is not a exact terminology. What is your
suggestion?

> 
>   Since a receiver may act upon received data, for syslog over
>    TLS, it is recommended that the server authenticate the client to
>    ensure that information received is authentic.
> 
> **this seems to weaken the claim earlier that TLS defends 
> against the listed threats - by now  I am feeling confused 
> about what protection is being offered by what.  To meet the 
> claims of s.2, I think we need both server and client to 
> check certificates for suitable identities and to follow a 
> chain to a trust anchor - I have no problem with describing 
> other scenarios but think that each such scenario should then 
> be qualified with a comment to the effect that this MAY not 
> defend against threats ... as identified in s.2

Perhaps "authentic" is not an exact term, how about "it is recommended that
the server authenticate the client to ensure that information received is
from trusted client."

> 
> 5.2.  Cipher Suites
> 
>      Operators MAY choose to disable older/weaker cipher 
> suites for TLS
>    despite the tradeoff of interoperability, for example, if 
> the cipher
>    suite specified in the specification is found weak in the future.
> 
> **suggest
> 
>     Operators MAY choose to disable cipher suites for TLS 
> that are regarded as too weak for the environment in which 
> this specification is being used, especially older cipher 
> suites.  This MAY lead to a reduction of interoperability.  
> It is likely that, in time, the cipher suite specified here 
> will become subject to attack and the use of it will too be 
> deprecated.

OK, thanks!

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

---

From: "Richard Graveman" <[email-masked]>
Date: Thu, 10 Jan 2008 03:46:54 -0500

> > will become subject to attack and the use of it will too be

First sentence, just: "Implementations MUST allow operators to disable
cipher suites."
Why operators do this and how old the suites are are totally irrelevant.

Second sentence: MAY -> may

Just my $.02,

Richard

---

From: "tom.petch" <[email-masked]>
Date: Fri, 11 Jan 2008 17:43:30 +0100

Snipping out the agreements, and taking dbh's point about this I-D being in A-D
Evaluation and so may be beyond comment:-), see inline

Tom Petch

----- Original Message -----
From: "Miao Fuyou" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Rainer Gerhards'"
<[email-masked]>; <[email-masked]>
Sent: Thursday, January 10, 2008 12:00 AM
Subject: RE: [Syslog] transport-tls-11 review

> cover the first case. I agree that is not a exact terminology. What is your

Weell, by certificate validation I mean following a chain of certificates back
until one reaches a trusted certificate, such as a root CA or trust anchor.  OK,
many - most? - people don't do that but I am not sure we should connive with
them.  I prefer certificate validation and certificate generation.  RFC2828 is a
fun read for this.

> the server authenticate the client to ensure that information received is

suggest

" it is recommended that the server authenticate the client to confirm the
identity of the client from which the information is received."

or something similar, that is that (any kind of) authentication authenticates an
identity that the other party is asserting, no more; trusted involves rather
more than that, that is having confirmed what the identity is, then that
identity is one that can be trusted.  Authentication may be 100% successful
after which you have established that the client is totally untrustworthy and
that this is a phishing attack:-)

Tom Petch