Re: Origin-signed responses

On Wed, Sep 06, 2017 at 11:48:49AM -0700, Jeffrey Yasskin wrote:
> On Sat, Sep 2, 2017 at 8:32 AM, Ilari Liusvaara <>
> wrote:
> > On Fri, Sep 01, 2017 at 09:35:27AM -0700, Jeffrey Yasskin wrote:
> - The main risk in just using server PKI keys is server accidentially
> >   signing a valid response.
> The second risk is that server PKI keys have to be stored online, so
> they're easier to steal than an offline key, and that's an unnecessary risk
> for packages which could be signed with an offline key.

Oh yeah, there is no technical reason to require signatures to be with
the same certificates the server uses.
> > 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), (Ed25519)
> >   and (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.

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

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.

> 2) Is this more sensitive than an attacker's page being able to write an
> <img src=>? 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.

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


Received on Wednesday, 6 September 2017 19:30:42 UTC