On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman <tony.put...@dyson.com> wrote:
> 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. > Yep, that should actually work just fine. 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. > Yes, I agree with you. OPTLS had a less linear key schedule. I think if you wanted to do 0-RTT you would have to have it be a pretend PSK as you suggest in your draft. I think that this and draft-putman are not competing, but rather that they > serve different use case > Agreed. It sounds like you have a set of use cases where you know how to predistribute the server key? This is the part we found challenging int he web context. -Ekr > s. 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>, 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 > 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
