Re: draft-thomson-httpbis-cant

[Ilari Liusvaara <[e-mail]>]

On Wed, Oct 22, 2014 at 03:10:45PM +0100, Stephen Farrell wrote:
> 
> First off, I like the idea - the more ways in which we
> can try push passwords a bit further off stage the better.
> So I hope this is taken up somewhere and progressed and
> gets deployed.
> 
> That said:
> 
> - section 2: I don't like the auth scheme name - this
> should work without X.509. I'd suggest "TLSClientAuth"
> would be a better thing to use.

Looks like the name is "ClientCertificate" (the first
paragraph)
 
> - 3.1: I assume this is solely for backwards compat?
> If not they who do we expect to use this? If so,
> please say so and encourage use of (hashes of) keys
> or certs instead.

It is not for backwards compatiblity. TLS 1.0-1.2
have the equivalent field. TLS 1.3 probably not.

And besides, having it available at HTTP level saves
a handshake attempt to obtain the list of acceptable
CAs.

> - 3.1: You should probably profile X.500 names for
> use here - requiring the full complexity of X.500
> (e.g. it allows for X.400 ORAddress as an option)
> would seem like a bad idea. Not sure where you could
> find that already done by someone else but it ought
> be somewhere (maybe some ldap thing?).

The matching looks the simplest possible: Raw opaque
binary blob (to be compared using memcmp()) Base64url
encoded.

> - 3.2: Someone needs to do a compare/contrast against
> websec's key pinning but also DANE and JOSE for this
> bit. Not sure its quite right now.

- This uses existing registry of hashes, whereas
  HPKP defines just SHA-256, DANE has its own set
  in registry and I think JOSE just defines SHA-1
  and SHA-256.
- Websec and JOSE pinning pins just keys inside
  certificates, whereas this pins whole certificates.
  DANE can pin either keys or whole certificate.

> - 3.2: You need to add support for hash(public-key)
> which could be done like DANE or even via RFC6920
> URIs if that made sense (no idea, so don't take this
> as me pushing an RFC I co-authored:-). That's needed
> for bare-keys TLS anyway, and is just a good plan (tm).

I read the section that if the certificate is RPK,
then the hash matches the RPK.

(Of course, this runs into trouble with identification).

> - somewhere: why not have a KeyIDType somewhere here
> where the client/server can signal what kind(s) of
> key identifiers (or containers) are being, or to be,
> used. Probably something that maps to an existing
> TLS construct. Who knows maybe someday someone will
> come up with a privacy-friendly way to identify
> public keys that'd even help with this in TLS1.2 and
> earlier? So having that here would be a good plan
> I think.

Identifying the public key itself runs into trouble
with identification.

If one does not use X509, one would presumably need
some sort of tag to identify public key (and actually
with X509, the CA can be such tag, since there is
no requirement for the client to trust the CA).

> - Its not clear to me how or if this ought be bound
> to the TLS session. I think that'd be a good thing
> to ponder, but I've not:-) OTOH, it'd be a pain to
> define this but also have it work via e.g. a TLS
> MITM as that would utterly make it meaningless as a
> strong client authentication scheme. Not sure what's
> doable there but maybe the UA could send an Authorization
> header field based on the challenge and a TLS extractor
> (RFC5704) value and its public key as at least an
> option that'd detect MITMs or maybe some other forms
> of attack.

It will be a new TLS session.

> - I'm sure you'll need changes to keep the http
> auth scheme police happy:-) [1] seems to have now
> achieved that status so copying from there may help.
> 
> S.
> 
> [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba


Another thing that isn't clear: The spec says that the
scheme can't be used with http://. What about HTTP/2
oppsec http://? If not via proxy, there is presumably
direct connection, suitable for using TLS client certificates.


-Ilari