- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Wed, 6 Dec 2017 23:15:54 +0200
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Dec 05, 2017 at 09:19:43PM +0000, Jeffrey Yasskin wrote: > Hi all, > > I've published > https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html > to follow up on > https://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0385.html with > a concrete proposal for the Signature header. > > I made several choices in this design where another tradeoff would be > totally plausible. Let me know where you'd prefer something different. > > Some interesting aspects of this update: > > * The signature covers the URL, so it's really a signed "exchange" rather > than just a signed response. > * To simplify the Signed-Headers header, it's not possible to customize > which parts of the request are included in the signature. Exactly the > method and effective request URI are included. > * The signing key can either be a certificate's key or a raw ed25519 public > key. The first supports origin-trusted certificates and other complex forms > of trust, while the second supports > https://github.com/mikewest/signature-based-sri and other ways a public key > might be trusted out-of-band. Attentive folks will notice that this means > signed exchanges are no longer necessarily *origin*-signed. > * Certificate chains are fetched and cached from a URL rather than bundled > into the Signature header. Normal use is likely to Push the chain for a > group of signed exchanges. > * There's a way to update the signatures for a response without re-fetching > the whole response. > > I'll be updating > https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html > as you point out things I should change. Looking at the draft some comments: Section 3.4: " Followed by the appended items from, for each response header field in exchange, in order: " Errant paragraph break? Section 3.6: "and parsing it as a TLS 1.3 Certificate message ([I-D.ietf-tls-tls13], section 4.4.2) containing X.509v3 certificates." Does this include four-byte TLS message header? I have seen some confusion with this in case of exported authenticators. Also, TLS 1.3 Certificate message contains a context field. How that should be set? always empty string? "1. The text string “certSha256”. 2. The byte string certSha256." This field does not seem if raw Ed25519 key (ed25519Key) is used? This section does not seem to clearly define signature format. The signature format is the same as used by TLS 1.3 (JOSE and COSE have different format for ECDSA signatures)? Also, should mapping entries for Ed25519 and Ed448 keys be specified (even if not MTI)? Section 3.6.1: "Validate that all certificates in path include “status_request” extensions with valid OCSP responses." While CA certificates might have OCSP responses, in practice these have unusuably long lifetime (months!). Section 3.6.2: "TLS 1.3 signs the entire certificate chain, but doing that here would preclude updating the OCSP signatures without replacing all signatures using that chain at the same time. What attack do I allow by hashing only the end-entity certificate?" That probably depends on if upper certificates can alter the interpretation of the end-entity certificate, instead of just having "pass or fail" effect. X.509 has all sorts of extensions that have all sorts of odd semantics. The computational complexity of X.509 chain validation is unknown, and might not be solvable in polynomial time. Section 4.1: "The use of a single Signed-Headers header field prevents us from signing aspects of the request other than its effective request URI ([RFC7230], section 5.5). For example, if an author signs both Content-Encoding: br and Content-Encoding: gzip variants of a response, what’s the impact if an attacker serves the brotli one for a request with Accept-Encoding: gzip?" Assuming receiver and all intermediates on path properly support Content-Encoding, that would just be a busted response, no? However if something does not get C-E right, things get a lot more complicated. Also, Signing Content-Encoding (and Content-Type) if any is a good idea... "Section 3.6 can succeed when some delivered headers aren’t included in the signed set. This accommodates current TLS-terminating intermediates and may be useful for SRI " Nit: There are TLS-terminating intermediates that just terminate TLS and pass the stream. Maybe you meant reverse proxies? Section B.1.2: The problem with RsaEncryption keys is not so much confusion with non-TLS protocols. The problem arises if: - Some server with private key supports TLS (or SSL) static RSA. - That server does not properly hide decryption failures. This is hard, and the advice up to TLS 1.1 on this was flawed. If those two conditions are met, then attacker can use the Bleichenbacher attack to forge signature for arbitrary message with the relevant key. Note that I said "Some server", not "the server". DROWN showed how common shared keys are. And often they were shared with some pretty badly configured servers. There have been some wrong use security bugs with ECDSA keys as well, but those did not let attacker forge signatures. Section B.2: Not signing accept-* does not seem to create worse problems than servers with busted negotiation (and there are probably a LOT of those)? Section B.2.1: Again "TLS-terminating proxies". You mean reverse proxies? -Ilari
Received on Wednesday, 6 December 2017 21:16:49 UTC