Re: Concrete format for signed responses

On Wed, Dec 06, 2017 at 03:59:34PM -0800, Jeffrey Yasskin wrote:
> 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:
> 
> > 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?

Oh, good.
 
> > 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.

I think after curdle-pkix goes to RFC, CABForum will probably allow Ed*
keys for EE certificates (but not CA certificates due to issues with
key protection). And EE certificates are the one that matters here.

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

That is EE certificates only. And it is 7 days.

Poking around a bit, it seems that the OCSP response on the native LE
X3 intermediate has lifetime of 1 year(!!!).

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

Well, it probably is OK if nothing can affect interpretation (only
validity) of the end entity certificates.

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

If something doesn't get C-E right, the impact is tring to decompress
brotli data as gzip data. It is possible that there exists some piece
of data that decompresses as both (obviously to something different).

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

Well, there are really three kind of things here:

- Just terminate TLS, leave data alone in both directions.
- Terminate TLS, mangle inbound data but not outbound data (usually
  to insert source address markers).
- Reverse proxy, mangles inbound and outbound data.

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

Yes.
 

-Ilari

Received on Thursday, 7 December 2017 17:18:59 UTC