On Mar 8, 2018, 6:25 PM -0500, Eric Rescorla <e...@rtfm.com>, wrote:
> > 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.
Agreed.
> >
> >
> > > 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.
That sounds right — the early application data key with OPTLS is `g^{sx}`
instead of `psk`.
Best,
Chris
> >
> >
> > > 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
