Re: Concrete format for signed responses

On Wed, Dec 6, 2017 at 1:15 PM, Ilari Liusvaara
<ilariliusvaara@welho.com> wrote:
> 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?

Yes, but appears to be a problem with xml2rfc rather than my
kramdown-rfc2629 source. The XML is <t><list>...</list>Text
<spanx>exchange</spanx> Text<list>...</list></t>.

> 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.

I didn't think very hard about this, but if I wanted to include the
4-byte message header, I think I'd have to say that it's a Handshake
message containing a Certificate
(https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#handshake-protocol).
I'll add a note clarifying.

> Also, TLS 1.3 Certificate message contains a context field. How that
> should be set? always empty string?

I think so, since it's not in response to a CertificateRequest.

> "1. The text string “certSha256”.
> 2. The byte string certSha256."
>
> This field does not seem if raw Ed25519 key (ed25519Key) is used?

Good catch.

> 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)?

I do say that the signing algorithm is as defined by TLS 1.3 section
4.2.3. Is there something more I should say?

> Also, should mapping entries for Ed25519 and Ed448 keys be specified
> (even if not MTI)?

("MTI"?) I believe that Ed25519 and Ed448 keys don't exist in the Web
PKI yet, although that could be out of date. Once they do, yes they
should have mandatory mapping entries.

> 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!).

Ah, so I need to set a maximum lifetime here. I'd vaguely heard that
Microsoft set a maximum lifetime for OCSP responses of 7 or 10 days.
Is that right? I'd like to match that.

> 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.

Ryan Sleevi said that signing just the end-entity certificate was the
right thing to do: https://github.com/WICG/webpackage/pull/91.

> 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.

Attacks usually consist of something not getting something else quite
right, and a goal here is to make attacks as difficult as possible
even in the face of some bugs.

> Also, Signing Content-Encoding (and Content-Type) if any is a good
> idea...

Right now I say that "Higher-level protocols SHOULD place requirements
on the minimum set of headers to include in the Signed-Headers header
field." I think it would make sense to give an example of a particular
protocol's decision here, but I'd want that to be a complete set of
required headers and not just one or two that we happen to call out.

> "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?

I'd imagined that reverse proxies were just one kind of
TLS-terminating intermediary, and may not be the only kind that add
headers. If that's wrong, I can switch to the narrower term.

> 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.

It seems like you're talking about accidental signing oracles here,
which are covered in
https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html#rfc.section.4.p.4.
Beyond that, I'm not sure what else to write in this section.

> 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)?

That is, you're comfortable signing only the URL?

> Section B.2.1:
>
> Again "TLS-terminating proxies". You mean reverse proxies?

See above.

Thanks for the comments! I've sent a PR at
https://github.com/WICG/webpackage/pull/93.

Jeffrey

Received on Thursday, 7 December 2017 00:00:22 UTC