Re: Origin-signed responses

On Wed, Sep 6, 2017 at 12:30 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Sep 06, 2017 at 11:48:49AM -0700, Jeffrey Yasskin wrote:
> >
> > On Sat, Sep 2, 2017 at 8:32 AM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> > > Such accidential signatures can come from
> > >   two sources:
> > >
> > >   1) Confusion with some other type of key exchange.
> > >   2) Confusion with some other type of signature.
> > >
> > >   The first is mainly risk for OID 1.2.840.113549.1.1.1 generic RSA
> > >   keys, as due to server misconfiguration, those can be used with
> > >   various broken key exchanges that may be exploitable to create valid
> > >   signatures. Other key algorithms, like 1.2.840.113549.1.1.10
> > >   (RSA-PSS), 1.2.840.10045.2.1 (generic ECC), 1.3.101.112 (Ed25519)
> > >   and 1.3.101.113 (Ed448) are not affected, or are affected much less.
> > >
> >
> > Thanks. It sounds like I need to restrict the kinds of keys that are
> > allowed to be used for these signatures instead of allowing the key from
> > any trusted certificate. I think I forgot to say it in the draft, but I'm
> > also expecting to identify exactly one signing algorithm for each key
> type,
> > instead of letting attackers specify the algorithm.
>
> These attacks against generic RSA keys aren't actually confusing
> signature algorithm with another signature algorithm, but exploiting
> non-signature algorithms to forge signatures.
>

Ah, got it. I've refined that note in my draft.

There were some key type confusion attacks against generic ECC keys too
> (there is apparently no "ECDSA" key type), but IIRC those did not allow
> forging signatures, unlike the attacks on generic RSA keys.
>
> I have seen some papers about confusions between signature algorithms,
> but those are seemingly about exploiting weak hash algorithms or
> trivial collisions.
>
> > > - Be careful with passing URLs to certificates. There are at least two
> > >   kinds of pitfalls here:
> > >
> > >   1) One needs to hash or MAC the certificate to avoid attacks.
> > >   2) The URL could point to some rather sensitive place (for probing or
> > >      exploiting bad GET handling).
> > >
> >
> > I don't follow this, sorry.
> >
> > 1) You're saying that if the attacker gets to specify their own
> > certificate, they can a) attack the verifying software or b) cause their
> > own package to be accepted for the origin?
>
> Well, being able to replace the certificate with different one with the
> same key in key exchange is regarded to break the key exchange
> security.
>
> Such certificate replacement is especially bad if client trusts other
> attributes besides the key and the domain names.
>
> TLS does have extension for sending the client certificate as URL. That
> extension does carry SHA-1 (yeah, I know) hash of the certificate in
> order to defend against certificate substitution.
>

That's an odd threat, but sure, it looks straightforward to include the
certificate chain in the signed bytes, like TLS does (
https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.3).

> 2) Is this more sensitive than an attacker's page being able to write an
> > <img src=https://sensitive.info/>? I don't really see how. I can imagine
> > that we'll need a failed certificate fetch to have the same result as a
> > successfully-fetched but untrusted certificate.
>
> Not really. I meant more references to resources that are not available
> in globally routed addresses (especially local LAN addresses).
>
> Requiring CORS preflights for external chains would likely take care of
> most of it.
>

An <img> tag can also refer to resources that aren't available in
globally-routed addresses, and we only require CORS for those if the page
wants to read the content of the image. Since we're not letting the
attacker (author of the "signed" response) read the content of the
certificate, just use it to validate the signature, I don't yet see the
need for CORS. What's the attack here?

I think the attacks along these lines in
https://tools.ietf.org/html/rfc6066#section-11.3 don't apply, since an
attacker who can get a client to download a package and then retrieve
certificates referenced from it, can also get the client to perform the
same fetches in other ways.

> - On stapling things to certificates, there is presumably also stapling
> > >   Certificate Transparency SCTs (and also STHs for interactive
> > >   clients).
> > >
> >
> > Yeah ... I'd expected folks would be including SCTs into the certificates
> > themselves, but I see they can also be transmitted through TLS or OCSP
> > extensions: https://tools.ietf.org/html/rfc6962#section-3.3. Would it be
> > sensible for this draft to require the SCTs to be embedded in the
> > certificate or OCSP, or do we need to allow them to appear separately
> too?
>
> The base certificate transprancy has three transport modes, and the
> specification requires clients to support all three:
>
> - Stapled in certificate.
> - Stapled in OCSP.
> - Dedicated TLS extension.
>
> The last is especially significant if the CA does not actually support
> CT. And stapling to certificate is technically more difficult to
> implement than stapling to OCSP (if webservers actually properly
> supported OCSP stapling, I would think that CAs would much rather
> staple CT to OCSP than certificates... If they did the stapling at
> all.)
>

I'm not sure it's worth supporting the use case of a CA that doesn't
support CT, since Chrome's going to require them all to support CT in 7
months (
https://groups.google.com/a/chromium.org/d/topic/ct-policy/sz_3W_xKBNY/discussion).
That said, if we staple OCSP responses using the TLS CertificateEntry
format, SCTs fit in exactly the same place.

Jeffrey