MIME-Version: 1.0
References: 
 <172593169876.2798510.2827700995204285294@dt-datatracker-68b7b78cf9-q8rsp>
 <01000191e6d89407-eb4e3bec-83e6-4288-b9c0-37f2ab8527b9-000000@email.amazonses.com>
In-Reply-To: 
 <01000191e6d89407-eb4e3bec-83e6-4288-b9c0-37f2ab8527b9-000000@email.amazonses.com>
From: Paul Wouters <paul.wouters@aiven.io>
Date: Thu, 12 Sep 2024 14:22:07 -0400
Message-ID: 
 <CAGL5yWZvsNZ4gSLQeWyJZxg83rZvD0+z5Eh3GrLmaN1HvScQ+A@mail.gmail.com>
To: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="000000000000d0fd540621f02f9f"
Message-ID-Hash: ID2FBYOSHMA66YHVLHF4TQFOOQRBVWXB
CC: The IESG <iesg@ietf.org>, draft-ietf-netmod-syslog-model@ietf.org,
 "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>,
 "netmod@ietf.org" <netmod@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_Paul_Wouters=27_Discuss_on_draft-ietf-netmod-sy?=
 =?utf-8?q?slog-model-32=3A_=28with_DISCUSS_and_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/netmod/6qN3hjc27R38A6rqFYFeo_tEMB4>

--000000000000d0fd540621f02f9f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 12, 2024 at 11:27=E2=80=AFAM Kent Watsen <kent+ietf@watsen.net>=
 wrote:

> Hi Paul,
>
> On Sep 9, 2024, at 9:28=E2=80=AFPM, Paul Wouters via Datatracker <noreply=
@ietf.org>
> 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=E2=80=99re raising is one that could=E2=80=99ve (should=E2=
=80=99ve?) 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 fo=
r
> 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

--000000000000d0fd540621f02f9f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 12, 2024 at 11:27=E2=80=AFAM =
Kent Watsen &lt;<a href=3D"mailto:kent%2Bietf@watsen.net">kent+ietf@watsen.=
net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div>Hi Paul,<br id=3D"m_7305009277099111434lineBreakAtBeginningOfMessag=
e"><div><br><blockquote type=3D"cite"><div>On Sep 9, 2024, at 9:28=E2=80=AF=
PM, Paul Wouters via Datatracker &lt;<a href=3D"mailto:noreply@ietf.org" ta=
rget=3D"_blank">noreply@ietf.org</a>&gt; wrote:</div><br><div><span style=
=3D"font-family:Helvetica;font-size:15px;font-style:normal;font-variant-cap=
s:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoratio=
n:none;float:none;display:inline">Related question: Is it one certificate+k=
ey that used for the TLS connection as</span><br style=3D"font-family:Helve=
tica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:=
400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px;text-decoration:none"><span style=
=3D"font-family:Helvetica;font-size:15px;font-style:normal;font-variant-cap=
s:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoratio=
n:none;float:none;display:inline">well as to sign data within the payload o=
f packets?</span><br style=3D"font-family:Helvetica;font-size:15px;font-sty=
le:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px;text-decoration:none"></div></blockquote></div><br><div><br></d=
iv><div><div>The issue you=E2=80=99re raising is one that could=E2=80=99ve =
(should=E2=80=99ve?) been discussed when the &quot;tls-client-server&quot; =
draft was being reviewed. =C2=A0</div><div><br></div><div>In that document,=
 only a single key+certificate is configurable, by each peer, for the TLS c=
onnection.=C2=A0 Specifically, there is not one key+cert for encrypting and=
 a different key+cert for signing.</div><div><br></div><div>I hear about th=
is Security best practice often, but never seen it used in the wild.=C2=A0 =
How important is this?</div></div></div></blockquote><div><br></div><div>Th=
ere is some confusion. I thought that there might be two indepdenent things=
:</div><div>1)=C2=A0 the TLS channel with its key and certs</div><div>2)=C2=
=A0 signed blobs of syslog data being transported</div><div><br></div><div>=
eg I thought that host A could sign its syslog messages, then log it over t=
he network (using TLS or not) and then it gets</div><div>stored but it is p=
rotected from modification at rest by the original signature. From the feed=
back now, I take it there is no such</div><div>thing and everything was jus=
t referring to the TLS key/certs used. So consider this issue resolved. No =
changes needed.</div><div>=C2=A0</div><div>Paul<br></div></div></div>

--000000000000d0fd540621f02f9f--