Re: Show support for HTTP Signatures at IETF

>
> Yes, but DIDComm *can* use features of a particular transport that
> enhances security, right?
>

Yes.


> For example, given two bindings for DIDComm, an HTTP one where there is
> no security (no use of TLS) and HTTPS where there is security (use of
> TLS), my expectation is that people would view the HTTPS one that uses
> TLS as more secure because there are two layers of security there (the
> DIDComm layer and the TLS layer). Since TLS is easy enough to use these
> days, it doesn't cost you much for that higher level of security.
>

It costs you a lot--not in computation or code size, but in deploying an
entirely separate trust model based on certs on one side, and sessions on
the other. If you're going to be doing that anyway, then fine. Plenty of
DIDComm will (e.g., to satisfy a mobile vendor whose push notification
channel demands it). But let's not say it's free otherwise.

The argument for why DIDComm might want to use HTTP Signatures is the
> same. Security is about layering... you never just depend on one
> security mechanism, like DIDComm, to protect you, mainly because stuff
> like this happens way more often than we'd like:
>
> https://threatpost.com/exploit-fully-breaks-sha-1/151697/
>
> My expectation is that if we were to use DIDComm, we'd want this as an
> option (especially because it provides an alternative to using TLS and
> the CA system to the DID ecosystem). Perhaps I'm missing something that
> makes this not possible using DIDComm?
>

Layering is indeed a useful security technique. However, years spent in the
cybersecurity industry convinced me that it is also often an
antipattern--particularly when there's a false equivalence made between
layers and defense in depth (often but not always the same). The best
defense in depth adds different *kinds* of defenses, not just more of the
same. HTTP Signature security and DIDComm security are both based on keys
and digital signatures (maybe even the *same* keys?)... Layers always add
complexity, and complexity is an important enemy of security. Layers
sometimes interact in subtle ways that we don't realize until a pentester
tells us. Layers always have a cost in one or more ways: documentation,
performance, deployment complexity, debugging costs, UX, etc. See a
discussion about such tradeoffs here
<https://www.plixer.com/blog/layered-security-approach/>.

I don't think the combination of DIDComm and HTTPS has much downside when
certs are already in play for independent reasons--but the combination of
DIDComm + HTTPS + HTTP Signatures may. By combining DIDComm's security with
HTTP signatures, a predictable outcome in some cases will be degraded
security, not improved security. The reason is that HTTP signatures is
designed for one-hop communication (or its virtual equiv) where the full
comm channel is encrypted with TLS already. In such circumstances, the
signature never reveals the signer's identity to anybody but the parties on
both ends of the pipe (and maybe intervening SSL visibility appliances).
However, DIDComm is designed to support multiple hops, possibly with mixed
transports (e.g., https --> mobile vendor push notification --> https). If
anything about HTTP signatures is transferred over a non-TLS pipe on one of
those hops (a simple mistake that well intentioned programmers could easily
make, trying to extend the "extra security" of HTTP signatures to their
entire transmission chain), then the non-repudiable signatures from HTTP
signatures visible in the intermediate hop degrade DIDComm's privacy
guarantee: an eavesdropper learns the identity of the sender.

None of this is an argument that HTTP Signatures are bad. I'm simply
disputing the assumption that DIDComm + HTTP Signatures is a non-brainer
improvement over DIDComm by itself. The security of DIDComm is already
world class; urging people to add something else is probably not good
advice in most cases.