Hi Ekr, Firstly, thanks for this. My primary reason for putting together draft-putman was to propose a handshake exchange which only uses a single asymmetric algorithm. If this proposal is extended to include raw public keys (I think these are already supported, but not mentioned in the text) and an ECDH-based MAC for client authentication, then this satisfies my constraints.
As a single data point, I can state that some of the IoT products that I'm working with already use static ECDH keys for client authentication (though not within TLS). Although OPTLS is able to use 0-RTT, I don't see how this capability could be used in this implementation, even if the client knows the server static key. Because SS is only included in the key schedule when the master secret is generated, the client_early_traffic_secret has no input secret. Conversely, if the SS is included in the key schedule as the PSK, then the certificate cannot be decrypted by a client which does not have the server static key. My conclusion is that, although this is usable with pre-provisioned ECDH keys, this is not the main use case. The different use case results in fewer properties; in particular (as noted), a client static key is not included in the key schedule. This means application data sent from the server before the client finished message is received is sent to an unauthenticated client (this is not the case with either PSK auth or with draft-putman). I think that this and draft-putman are not competing, but rather that they serve different use cases. They could be synergistic, such that this draft provides a mechanism for distributing a static key which could later be used in a draft-putman exchange; however, the natural continuation would be to use a resumption PSK, so this would only be useful if there were a long gap between session, which seems unlikely. Regards, Tony From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Christopher Wood Sent: 07 March 2018 01:26 To: <tls@ietf.org>; Eric Rescorla Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 Thanks for putting this together! I’m in favor of the mechanism and look forward to discussing it. Negotiating with signature_algorithms is a simple way to roll this out, it fits in cleanly with the key schedule, and the benefits outlined in the introduction (PRNG hardening, plausible deniability, etc.) seem worth the effort. Although the approach has its roots in OPTLS, we will certainly need to re-assess its impact on the handshake. (I know of some folks actively working on this.) We also need to spend more time thinking about the open issues — specifically, the story around early data encryption. This variant has the benefit of enabling early data with public key encryption, as opposed to (trackable) symmetric key encryption. It’s unclear to me whether or not we need to address the static share publication issue for this benefit. Anyway, thanks again for the draft. I’ll read it carefully before London. Best, Chris On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>>, wrote: Hi folks, Here's another entry in the DH-only pile. I've just posted: draft-rescorla-tls13-semistatic-dh-00 This implements a semi-static DH exchange mostly borrowed from OPTLS [0]. There are obviously connections with draft-putman, but this is more oriented towards implementing a 1-RTT style exchange where the client has no foreknowledge of the server's capabilities (though it's extensible to 0-RTT) than towards pre-distributed DH keys, and has less invasive changes to the key schedule. We'd like 10 minutes to discuss this in London. Thanks, -Ekr [0] http://ieeexplore.ieee.org/abstract/document/7467348/ _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
