Call for review on configuration of quinn in p2p setting with self-signed certificates

[thomaseizinger]

I am experimenting with usage of quinn in a p2p setting and built the following prototype: https://github.com/thomaseizinger/xtra-quinn-prototype

The gist of the code is here: https://github.com/thomaseizinger/xtra-quinn-prototype/blob/main/quinn-p2p-config/src/lib.rs with tests on how it is used here: https://github.com/thomaseizinger/xtra-quinn-prototype/blob/main/quinn-p2p-config/tests/lib.rs

I also opened an issue with a call-for-review: https://github.com/thomaseizinger/xtra-quinn-prototype/issues/2

Any input on whether or not the direction I am going in is sane would be greatly appreciated :)

[Ralith]

IANA cryptographer, but a few thoughts:

• You might be interested in pursuing support for raw public keys (RFC 7250) in rustls, which would relax the requirement for a fake domain name, and make handshakes a bit lighter besides.
• I'm not sure what requiring client certificates to be self-signed accomplishes, vs. accepting any client certificate.
• It's not clear how your clients determine the expected public key for the server. This is a key aspect of your cryptosystem design.
• It's not clear what specific security objectives you're pursuing. Without knowing exactly what you're trying to accomplish, it's difficult to judge if you've succeeded.

[thomaseizinger]

Thank you!

You might be interested in pursuing support for raw public keys (RFC 7250) in rustls, which would relax the requirement for a fake domain name, and make handshakes a bit lighter besides.

I guess you are talking about https://github.com/rustls/rustls/issues/423?

I'm not sure what requiring client certificates to be self-signed accomplishes, vs. accepting any client certificate.

Correct me if I am wrong but accepting any client certificate would allow clients to take whatever identity they want (as long as they can get ahold of the certificate which is easy because it is public knowledge to the server and effectively not bound to a domain) whereas self-signed assures that the client is in possession of the private-key. My intention is to use this for authorization purposes:

• Client A connects to server: Lets call this connection 1
• Client A uses an API on server via connection 1: Server associates Client A's identity with the created entity Foo in database
• Client A re-connects to server: Let's call this connection 2
• Client A uses a different API to modify Foo: Server authorizes client against identity stored alongside Foo

It's not clear how your clients determine the expected public key for the server. This is a key aspect of your cryptosystem design.

The idea is to communicate this out-of-band.

It's not clear what specific security objectives you're pursuing. Without knowing exactly what you're trying to accomplish, it's difficult to judge if you've succeeded.

Thanks, I should have probably stated that more clearly. Will summarize here and then update the prototype README as well.

What I need is:

• All parties (clients and servers) need stable identities and authorize actions against these.
• Who to connect to is communicated out of band and the a priori known identity forms an expectation on who to connect to.

[Ralith]

I guess you are talking about rustls/rustls#423?

Right. From discussion there it looks like there may be a more modern, TLS 1.3 native approach than RFC 7250; in any case, some amount of work on rustls would be required to expose it.

self-signed assures that the client is in possession of the private-key

To present a self-signed certificate, only the certificate itself is required; you don't need access to the private key, because the signature has already been constructed. Proving ownership of a private key requires e.g. having the client sign a unique server-controlled nonce, so that the resulting signature cannot be reused by a third party in the future. There may be more to it than that, you'd have to ask a real cryptographer, but the certificate alone isn't getting you much. I know Mumble uses a trust-on-first-use client authentication scheme like you describe, maybe investigate the details of that?

[thomaseizinger]

To present a self-signed certificate, only the certificate itself is required; you don't need access to the private key, because the signature has already been constructed. Proving ownership of a private key requires e.g. having the client sign a unique server-controlled nonce, so that the resulting signature cannot be reused by a third party in the future.

You are right, thanks for pointing this out!

The correct pathway forward seems to be to support something like RFC 7250 properly, so it gets review by a lot of eyes and then adopt it downstream.

Thank you for your comments!

[Ralith]

No problem, and good luck!