On Mon, Jun 10, 2019 at 12:43:26PM +0100, Daniel P. Berrangé wrote:
On Mon, Jun 10, 2019 at 12:19:32PM +0100, Richard W.M. Jones wrote:On Wed, Jun 05, 2019 at 06:19:20PM +0100, Daniel P. Berrangé wrote: > > +* `tls-verify-peer`: This optional parameter may be `0` or `1` to > > + control whether the client verifies the server's identity. By > > + default clients SHOULD verify the server's identity if TLS is > > + negotiated and if a suitable Certificate Authorty is available. > > I'd prefer if this is a "MUST" for the default value to be 1, if > omitted. "SHOULD" here means that's what implementations ought to do, and most will do it by default, but it leaves some leeway for implementations which cannot or choose not to verify the peer for whatever reason (even though we know that is unsafe in some MITM cases). I've tried to avoid mandating implementations except when it's absolutely necessary. > > +### TLS certificates directory > > + > > +The `tls-certificates` parameter (if used) refers to a directory > > +containing the Certificate Authority (CA) certificates bundle, client > > +certificate, client private key, and CA Certificate Revocation List. > > + > > +These are all optional except for the CA certificates bundle. > > + > > +The files in this directory SHOULD use the following names: > > + > > + Filename Usage > > + -------------------------------------------------- > > + ca-cert.pem CA certificates bundle > > + client-cert.pem Client certificate > > + client-key.pem Client private key > > + ca-crl.pem CA Certificate Revocation List > > QEMU suports a "dh-params.pem" file for the diffie-hellman parameters. > > With PSK, it uses a "tls-creds-psk" file with optional dh-params.pem > file too. This is really the crux of the issue that prevents me from getting a submitting draft. I think there are three ways forward: (1) Mandate the QEMU-style certificates directory, as outlined above (with Dan's amendment). This requires a small change to libnbd. It is compatible with nbd-client albeit reducing the "flexibility" os what nbd-client allows. (2) Add tls-* parameters for each individual file. Requires substantial changes to QEMU and libnbd. Flexible but you're going to end up with very long TLS URIs. (3) Drop all the TLS parameters related to the certificate and key names / paths. It's a free-for-all until someone else decides what's best to do.The tension in these choices is a reflection on two different views on what the URI should be used for a) URI as a way to identify what server to connect to b) URI as a way to identify what server to connect to *AND* express tunable params used to create the connection By providing the TLS credential path parameters we're moving into the territory of option b). Stuff required for option a) is pretty unambiguous & easily standardized, but option b) is likely always going to be painful as you venture into terrority of things which are specific to the implementation choices. For example if an application uses NSS instead of GNUTLS, then the notion of certificates paths is very different - NSS uses a completely different data file format for storing certs. A single DB containing all data, not individual PEM files. Even with individual PEM files, as discussed here, we have potential application specific naming needs. To me this suggests we should stick to option a) and only document the information needed to identify the server.
When comparing to other URI specifications, option a) seems more suiting as well. If you (or anyone else) really want the connection parameters to be provided in the same string, then that can still be adapted later on as this specification is not limiting in that regard. Martin
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Attachment:
signature.asc
Description: PGP signature