Subject: draft-thomson-httpbis-cant

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 15:10:45 +0100

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.

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

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

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

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

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

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

- I'd like if this were commensurate with HOBA [1]
so that in principle the same key pair could be
used. That's probably not that important to anyone
else though;-) And of course in contrast to what
I just suggested HOBA would work via a TLS MITM
but that's justified by HOBA's primary goal of being
a password replacement drop-in, whereas I think
you're aiming higher here.

- 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Oct 2014 17:52:39 +0300

> would be a better thing to use.

Looks like the name is "ClientCertificate" (the first
paragraph)
 
> please say so and encourage use of (hashes of) keys

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.

> be somewhere (maybe some ldap thing?).

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

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

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

> earlier? So having that here would be a good plan

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

> option that'd detect MITMs or maybe some other forms

It will be a new TLS session.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 08:09:38 -0700

> would be a better thing to use.

I was aiming for a tight scope, clearly you would like to expand this.
I'm not fundamentally opposed to that, but it's a lot more work.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 16:59:42 +0100

> I'm not fundamentally opposed to that, but it's a lot more work.

Well, not necessarily a lot, but sure I guess it might make
most sense to see what'll be needed so that HTTP/2.0+TLS1.3
can do at least as well as but hopefully better than the
kind(s) of client auth possible with HTTP/1.1+TLS1.2. And
then do that. I suspect the embedded/small-devices might
make a non-X.509 based approach worthwhile though.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 17:07:32 +0100

> Looks like the name is "ClientCertificate" (the first

Yup. I'm suggesting a change. Which as Martin noted
might amount to a different scope.

> a handshake attempt to obtain the list of acceptable

But turns out that (the acceptable CA list) doesn't work
well except in enterprise cases, in which case it's probably
a no-brainer anwyay.

> binary blob (to be compared using memcmp()) Base64url

Matching isn't the problem here, but rather en/de-coding
and presentation. Its worth being less flexible than is
allowed by X.500 names.

>   DANE can pin either keys or whole certificate.

Right. There're a few things to check is the point and
a few nearly-trivially different choices to make.

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

Maybe just more clarity is all that's needed then. And
its easily fixed regardless.

> no requirement for the client to trust the CA).

I'm suggesting to use whatever TLS uses to identify
the public key id/container. Again, not a huge deal.

> It will be a new TLS session.

Sure. Still worth figuring out though.

> direct connection, suitable for using TLS client certificates.

Good point. I agree that needs to be figured out and
that there're a few possible sensible answers that
could be offered.

S.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Oct 2014 11:27:13 -0700

> and presentation. Its worth being less flexible than is

I considered using RFC 4514 (I think that's right), but was convinced
to use a direct binary translation by someone.

The reasoning was simple: 1) it's much, much easier to do and 2) the
use case has been proven to be of marginal use at best (there was the
suggestion that it might be deprecated from day zero), so lavishing
attention on it wasn't seen as particularly productive.  I'm happy to
adjust as necessary and use whatever people want to do.