----- Original Message -----
From: "David Harrington" <ietfdbh@comc...>
To: "'tom.petch'" <cfinss@dial...>; "'Miao Fuyou'" <miaofy@huaw...>;
"'Rainer Gerhards'" <rgerhards@hq.a...>; <syslog@ietf...>
Sent: Thursday, November 29, 2007 12:12 AM
Subject: RE: [Syslog] transport-tls-11 review


> Hi,
>
> Let me remind the WG that this document is in IESG review.
>
> We are no longer doing fine-tuning/wordsmithing. We are fixing the
> problems raised by the IESG. So unless the wording is **broken** we
> shouldn't be trying to fix it now.
>
> What IESG-raised issues are we responding to?

My substantive issue is the one of applicability, essentially replying belatedly
to Chris's post of 15Oct07 which in turn I see as a response to Sam's post of
7Sep07.

I think that the new text does not sit well with the
old text, that we need to spell out more clearly eg that if you do not have a
client certificate, then TLS will not perform client authentication and so
unless you are authenticating by another means, there will be no defence against
masquerade eg the new section 5 may require us to modify section 3.

Also, there are forms of TLS with authentication where no certificates are
required and we should cater for those; they may become - I hope - quite
widespread.

I know - it would have been better to have made these comments in October:-(

Tom Petch


>
> dbh
>
> > -----Original Message-----
> > From: tom.petch [mailto:cfinss@dial...]
> > Sent: Wednesday, November 28, 2007 12:13 PM
> > To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf...
> > 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
> >
> > 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)
> >
> > 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
> >
> > 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
> >
> > .  If a server does not
> >    have a certificate and key/pair configured
> > **unclear what the solidus is doing - '/' usually means either/or
> >
> >    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.
> >
> >   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
> >
> > 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.
> >
> >
> > _______________________________________________
> > Syslog mailing list
> > Syslog@list...
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
>
>


_______________________________________________
Syslog mailing list
Syslog@list...
https://www1.ietf.org/mailman/listinfo/syslog