On Thu, Sep 12, 2024 at 11:27 AM Kent Watsen <[email protected]> wrote:
> Hi Paul, > > On Sep 9, 2024, at 9:28 PM, Paul Wouters via Datatracker <[email protected]> > wrote: > > Related question: Is it one certificate+key that used for the TLS > connection as > well as to sign data within the payload of packets? > > > > The issue you’re raising is one that could’ve (should’ve?) been discussed > when the "tls-client-server" draft was being reviewed. > > In that document, only a single key+certificate is configurable, by each > peer, for the TLS connection. Specifically, there is not one key+cert for > encrypting and a different key+cert for signing. > > I hear about this Security best practice often, but never seen it used in > the wild. How important is this? > There is some confusion. I thought that there might be two indepdenent things: 1) the TLS channel with its key and certs 2) signed blobs of syslog data being transported eg I thought that host A could sign its syslog messages, then log it over the network (using TLS or not) and then it gets stored but it is protected from modification at rest by the original signature. From the feedback now, I take it there is no such thing and everything was just referring to the TLS key/certs used. So consider this issue resolved. No changes needed. Paul
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
