David, Thank you for pointing out RFC5489. We have a well-established PKI in our data centers, and our security team prefers PKI instead of shared keys for the extra level security against the issues with the distribution of shared private keys. Having said that, we understand that your suggestions may be attractive for the environments where there is no PKI in place. I assume Ceph can have both methods (shared key vs separate public/private keys) if there are any takers to implement the shared-key option. Regards, Kadir On Wed, Mar 7, 2018 at 4:42 AM, David McBride <dwm37@xxxxxxxxx> wrote: > On Wed, 2018-03-07 at 11:15 +0000, John Spray wrote: > >> I'm curious about the motivation for TLS in particular, as opposed to >> using a stream cipher (plain AES-256 or similar) based on the >> existing cephx shared secrets and authorization tickets. Because the >> endpoints are already authorized, it seems like it should be possible >> to avoid introducing an additional set of certificates. > > While the implementation described appears to use certified public keys > as the basis for authentication over TLS, pre-shared key cipher-suites > are also available; see, for example, RFC 5489: > > "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)" > https://tools.ietf.org/html/rfc5489 > > I believe that cephx secret keys, or some derivative of them, could be > sensibly used with such a scheme? > > It will likely be easier to convince others that it is safe to rely on > an over-the-wire encryption mechanism if it is based on an existing > peer-reviewed scheme. > > Kind regards, > David > -- > David McBride <dwm37@xxxxxxxxx> > Computing Officer, University of Cambridge -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
