Re: Binding HTTP signatures (RFC 9421) to TLS

Hi David,


> HTTP message signatures is trying to sign the abstract HTTP message, in a
> way that still passes through intermediaries and the various different ways
> they can be encoded. And so it paid an inordinate amount of complexity to
> try to sign things in a way that was independent of these transforms.
>
> But by adding a channel binding, none of that applies anymore. So all the
> complexity seems to be a waste, because you're not actually signing an
> abstract HTTP message. You're signing a particular channel that carried the
> HTTP message.
>
> Have you considered instead something closer to HTTP auth? E.g. RFC 9729
> signs a channel binding.
> https://www.rfc-editor.org/rfc/rfc9729.html
>

Thanks for the background. Yes, RFC 9729 would have the security properties
we want. However, there is currently momentum behind adopting RFC 9421 at
Web Bot Auth, in particular for its implementation- and proxy-friendliness.
Therefore, my thought was that extending 9421 with an optional channel
binding might be the easiest path to adoption for those who don't need
proxy-friendliness.

One difficulty I'd like to point out about extending 9421 is how to
negotiate its use. In particular, we would need to convey to the client out
of band whether the server supports TLS binding or not. However, in the
case of Web Bot Auth, we might be able to solve this by including this
information in the Web Bot Auth key key directory:
https://datatracker.ietf.org/doc/html/draft-meunier-http-message-signatures-directory-04

In any case, I'll make sure we discuss 9729 as an alternative.

Best,
Chris P.