Subject: [Syslog] transport-tls-11 review

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 21 Nov 2007 09:23:38 +0100

Hi all,

I reviewed tls-11 today. Some notes:

Section 1.1: shouldn't it simply refer to -protocol for terms defined
there? I think it makes it more consistent.

Section 4.2:

===
   Authentication in
   this specification means that the recipient of a certificate must
   actually validate the certificate rather than just accept a
   certificate.
===

Is this "must" intentionally in lower case? If so, is this plausible?

Section 4.3.1: typo "tranport"

Section 5.1:

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

----

Other than that, I find the draft is quite acceptable.

Rainer

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

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 27 Nov 2007 15:01:25 -0800

Hi Rainer,

Thanks for our comments, in-line, 

Regards,
Miao
> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2007 12:24 AM
> To: [email-masked]
> Subject: [Syslog] transport-tls-11 review
> 
> Hi all,
> 
> Section 1.1: shouldn't it simply refer to -protocol for terms 
> defined there? I think it makes it more consistent.

Agree, so we should only leave "TLS client" and "TLS server" to be define in
Syslog/TLS darft, right? 

> Is this "must" intentionally in lower case? If so, is this plausible?

Yes, intentionally.

> Section 4.3.1: typo "tranport"

OK

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

Need more opinion from the working group.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 28 Nov 2007 08:16:13 +0100

Hi Miao,

a few comments, rest snipped...

> Agree, so we should only leave "TLS client" and "TLS server" to be

That is my suggestion...

> > Is this "must" intentionally in lower case? If so, is this
plausible?

IMHO it is confusing if you use "must" in a non-normative way. If I were
to implement it (and did not know about this discussion), I'd wonder if
I "MUST" validate ... or if the "must" is a suggestion, like a "SHOULD".
Why not use "SHOULD" in the first place?

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Wed, 28 Nov 2007 18:13:00 +0100

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Nov 2007 18:12:07 -0500

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?

dbh 

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 12:13 PM
> To: Miao Fuyou; 'Rainer Gerhards'; [email-masked]
> Subject: Re: [Syslog] transport-tls-11 review
> 
> <snip>
> > >
> > > ===

---

From: "tom.petch" <[email-masked]>
Date: Fri, 30 Nov 2007 11:13:04 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Miao Fuyou'" <[email-masked]>;
"'Rainer Gerhards'" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 29, 2007 12:12 AM
Subject: RE: [Syslog] transport-tls-11 review

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Nov 2007 12:18:17 +0100

On Fri, Nov 30, 2007 at 11:13:04AM +0100, tom.petch wrote:
 
> 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.

Can you be more concrete what you have in mind?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "tom.petch" <[email-masked]>
Date: Fri, 30 Nov 2007 16:57:44 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; "'Miao Fuyou'"
<[email-masked]>; "'Rainer Gerhards'" <[email-masked]>; "syslog"
<[email-masked]>
Sent: Friday, November 30, 2007 12:18 PM
Subject: Re: [Syslog] transport-tls-11 review

> Can you be more concrete what you have in mind?
 Using SRP for TLS Authentication,

http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-14.txt

is one such; it allows for server certificates and for the absence thereof.

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)

  ftp://ftp.rfc-editor.org/in-notes/rfc4279.txt

is another but, as it points out,

   If the main goal is to avoid Public-Key Infrastructures (PKIs),
   another possibility worth considering is using self-signed
   certificates with public key fingerprints.

Tom Petch