Yes, we need. But, it may not harm. The scenario may look like this: Client already has the locally stored hostname/url of a Syslog server(A). It sends a resolution request to DNS server, then get an IP from DNS server. When the response is falsified by an attacker, the IP address is fake, in fact the IP address is for Syslog server B. After client starts to talk to server B using the fake IP address, it gets B's certificate. There is hostname in the certificate. Client finds the hostname (B) in the certificate and locally stored hostname (A) are not consistent, then it disconnect the TLS connection. This is correct Syslog/TLS behavior we expected. One may argue that server B may send a certificate with Server A's hostname in its CN/SubjectAltName. In such case, there must be something wrong at CA when issuing certificate or private key for the certificate is compromised. It's CA or Certificate owner's job to make it correct. Syslog/TLS can do nothing in this case.
> -----Original Message----- > From: Balazs Scheidler [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 30, 2006 9:15 PM > To: Miao Fuyou > Cc: 'David B Harrington'; [EMAIL PROTECTED] > Subject: RE: [Syslog] Summary of the syslog/tls issues resolving > > On Sun, 2006-04-30 at 17:30 +0800, Miao Fuyou wrote: > > Another problem of using DNS is: name resolution itself is > not secure > > if DNSSEC is not used (true im most cases). Dependency on DNS may > > introduce new security vulnerable to Syslog/TLS. > > > > Client should use knowledge a priori to check server's certificate, > > such as URL, if it is available. > > Yes, you need forward DNS resolution in this case too. (e.g. > hostname in URL -> IP address) > > -- > Bazsi > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
