Hi Greg, Tal, On Thu, Nov 26, 2020 at 12:14:42PM -0800, Greg Mirsky wrote: > > On Wed, Nov 25, 2020 at 1:56 AM Tal Mizrahi <tal.mizrahi.phd@xxxxxxxxx> > wrote: > > > > On Tue, Nov 24, 2020 at 11:30 PM Greg Mirsky <gregimirsky@xxxxxxxxx> > > wrote: > > > > I would suggest to consider a new IOAM option that incorporates an > > HMAC, which can be used alongside the conventional trace options. This > > would allow an optional integrity protection capability for those > > specific implementations that require it. This new option could be > > defined in a new draft, allowing the data draft to proceed to > > publication. > > > GIM>> I think that proceeding without addressing the essential security > issue of the protocol might be premature and may produce implementations > that are vulnerable to attacks. Thanks for raising this topic. Based on the discussion so far and skimming the first few sections of the draft, I expect that I would put a discuss ballot in to ensure the availability of a security mechanism such as this, which in effect would negate the intent to "allow the data draft to proceed to publication". That said, my stance could change as the thread continues or when I take a closer look at the whole document, so it is okay (from my point of view) if you (Tal) choose to wait and see if this does end up being a discuss point. That said, I'd of course prefer if you and Greg can find a solution and get it into place now :) Thanks, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
