W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: Concrete format for signed responses

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>
Message-ID: <20171206211554.GA17237@LK-Perkele-VII>
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

"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

Section B.2.1:

Again "TLS-terminating proxies". You mean reverse proxies?

Received on Wednesday, 6 December 2017 21:16:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 6 December 2017 21:16:58 UTC