Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt

<inline>
Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>; <robert.horn@agfa.com>;
<syslog@ietf.org>
Sent: Tuesday, May 13, 2008 12:17 AM
Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt

> Hi Rainer,
>
> Comments below:
>
> <snip>

> [Joe] We are not talking about HTTPS we are talking about syslog.  What
> applies to one may not necessarily apply to the other (HTTP provides
> other ways to authenticate the client etc.).  In addition HTTPS
> authenticates the server in most cases.  In any case, I don't think you
> can claim confidentiality if you do not take care of masquerade or
> man-in-the-middle as either will result in a breach of confidentiality,
> you are still vulnerable to active attackers.
>
> I believe that implementations need to support mutual authentication and
> authorization with certificates.  The recommended mechanisms for this
> probably still need some discussion, however I think it is important to
> provide this capability.  I think what is more to the point in the
> current discussion is what is required by default.  I would like to
> suggest that server authentication, certificate path validation and
> authorization be required by default, because I without this I don't
> think any security goals are met.  I would also suggest that by default
> clients should present and authenticate with a certificate, however a
> server does not necessarily need to perform path validation or
> authorization, it can just record the certificate (or fingerprint) that
> carries the public key used in the authentication so it can be validated
> at a later time.

Joe

I am concerned, as I think Robert is, about the mixing of protocol and policy;
the former we should define, the latter I am dubious about, seeing it as a
moving target as practices change (one day we may have widespread PKI - or maybe
not:-); at least we should separate it out, section 5 not section 4.

I remain concerned about the number of changes proposed in -12.  Reviewing -11,
last November, we did discuss whether or not the I-D
should give guidance on certificate management and the views I saw then said
not. In fact, dbh asked what IESG-raised issues are we responding to, that is,
given the status of the I-D, the only issues should be IESG ones.  Then, I could
answer that question, now I cannot and so wonder what drives these changes

Historically, the November 2005 IETF meeting led to a proposed charter which was
rejected by the IESG for lacking a mandatory-to-implement security mechanism.
Our AD then guided us through developing a threat model, the rough consensus on
which I believe this I-D accurately records.  This led to a charter which was
acceptable to the IESG.  So that threat model - section 2 - for me is a given.
Change that and you change the charter:-)

During the discussions on threats, rough consensus emerged for TLS.  There was
no discussion about how authentication would be done, no discussion of how
strong the security should be.  The first draft of this I-D took certificates
for granted but did debate the need for client-side authentication. By -11, I
thought that we had a reasonable consensus and should only change what the IESG
wants us to; and that I do not see.

Tom Petch

.

>
> This requires configuration on the client, but not necessarily on the
> server.
>
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog

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