mikebishop / http2-certs Goto Github PK

Just http2-certs perhaps.

This usage creates another context in which the same key is used for signing in two different contexts. We need to be careful to a) make sure that those signatures can't be transplanted elsewhere, and b) document that we have done so.

I am adding the requirement to expose a new API to TLS libraries in the exported authenticators draft that returns the signature algorithms that the library is willing to validate. This should be incorporated into the CERTIFICATE_REQUEST frame to help the other side choose a certificate that can be validated.

From Andrei:

nearly all available certs today use RSA-PKCS1.5 rather than RSA-PSS. Are you relying on all sites and clients getting new certs to support this?

The bitmap is about the signatures which we support in the PROOF frame, not about how the certificates themselves are signed. Now, whether existing RSA certs can generate RSA-PSS signatures is a question for Crypto folks – I would think that an RSA key can be used for multiple signing schemes, but I could also be wrong. Issue to track confirming.

Hi, there is a specification Signinging HTTP messages that can be used for authentication and that is very lightweight - I think it can be implemented nicely in a week - and that does not require any changes to TLS as it is now. This makes it very useful at least for dealing with the current transition where your spec is not finished, (and so browsers have not implemented it) keygen has been removed from most browsers with no replacement in sight that I know of, and TLS does not play nicely with HTTP/2.0 as your spec so very clearly explains. (Thanks for bringing so much clarity to this space!)

I have used HTTP-Signature in JS apps to authenticate an app to various servers, and am also implementing a standalone library for clients and servers for it too. That is clearly within my skill and time level, whereas implementing things at the TLS layer, would require a lot more effort and knowledge on my part.

I asked the question on their github repository and I ask it here, as to how the two specs complement each other, and what additional security this one brings. I ask so that I can understand the limitations of using only HTTP-Signatures, and to then also explain to people how both will be able to work together, and why people should support this work too - even though it is further off. Ie what are the limitations of the HTTP-Signatures method of authentication that I need to make people aware of, with the hope that this spec will fix that - understanding of course that no security technology is perfect, and so that all come with limitations.

Requiring the peer to cache everything you send for the lifetime of the connection invites DoS attacks on memory consumption with giant/numerous (possibly fake) certs. There should be a way to signal that a certificate/request has been discarded; senders would need to re-send if they want to use in the future.

Personal opinion, plus Andrei's feedback:

I really dislike the bitmap approach -- I'd much rather use the TLS IANA codepoints that exist. It's more extensible, better layered (can just relay uninterpreted data to the crypto components)

• Can we just get this information from the TLS stack?
• Do we need a TLV-style equivalent to the SETTINGS frame?
• Get rid of unsolicited certs and put this back in REQUEST?

This would simplify the SETTINGS value and reconcile it with the algorithm field on the PROOF.

From Andrei:

if you require support for this OID [subjectAltName] in the CERTIFICATE_REQUEST, then you have to define matching rules (see https://tools.ietf.org/html/draft-ietf-tls-tls13-12#section-6.3.3.2 for an example).

I would have thought they were already defined somewhere, but if not….

HashAndSignatureAlgorithm is a sixteen-bit value, but allowed values are currently limited to sixteen (i.e. 4 bits). Keep the current length so we can reuse TLS-defined values, or shave? Even if we need to overflow into additional SETTINGS values someday, eight bits seems more than sufficient.

From Andrei:

all frame names etc. are very cert-specific. You may want to rename them “authenticators” or similar, and include auth type fields to accommodate e.g. raw keys or PSK. Or you could say non-certificate auth would have to use new frame types defined in a new spec.

I was initially uncertain that there was a use-case for proving multiple raw keys (since what we’re ultimately trying to prove with certs is a strong name binding), but coupled with DANE records as supporting data, I think you could get a name binding off a raw key as well. Browsers probably won’t support it, but that doesn’t mean the protocol couldn’t allow the flexibility to do it for IoT.

Right now we don't have an explicit correlation between this and the CERTIFICATE_NEEDED frame, which I think is OK, but it means that a server has to process USE_CERTIFICATE with no expectation of it actually addressing its requirements as expressed. Basically, it has to decide to authorize the request or not on the merits of what it has.

That potentially leads to a race: client thinks certificate X is what this request needs, so it sends USE_CERTIFICATE(X) after the HEADERS. Server receives the request, decides that it wants a certificate, so it sends CERTIFICATE_NEEDED and CERTIFICATE_REQUEST as soon as it processes HEADERS. Then, when the server receives the USE_CERTIFICATE(X), it decides to reject the request. The client sees the CERTIFICATE_NEEDED/CERTIFICATE_REQUEST, answers the request with CERTIFICATE(Y)/USE_CERTIFICATE(Y), but then finds the next thing it receives is a 4xx status code.

It is possible to trace the USE_CERTIFICATE(X) back to the CERTIFICATE and any CERTIFICATE_REQUEST that was made to discover that this isn't in fact a response to the CERTIFICATE_NEEDED that the server made, but it's a pretty long path to follow. Should we describe that case?

Currently, we do a single TLS export for the session, then sign it repeatedly with every key used by either peer. Brian S. raises the question of whether it would be better to incorporate the Cert-ID into the exported value so that each signature is of a unique value.

I'm not aware that this is necessary, but I'd like to be officially told that by someone whose job is crypto. If it's needed, it's easy enough to add.

From Andrei:

{#http-certificate}: “A certificate which specifies a trust anchor MAY be omitted” – why would one ever want to send the root? The peer can’t use it in any way, and in TLS, it’s been a source of interop issues.

SHOULD? MUST? Though, back to DANE, if DNS says that the cert must chain to a CA that the client doesn’t otherwise trust, wouldn’t the client need to see that cert to validate the signature?

I defer to my TLS brethren on this issue.