On Fri, Mar 24, 2017 at 12:16:48PM -0400, Russ Housley wrote: > > > I agree with David here. Specifically, I think. > > > > - The base specification should continue to forbid certificates in > > combination with PSK > > - We should at some point contemplate an extension that allows the use of > > certificates in combination with PSK > > - The base spec should be factored in such a way as to make that extension > > easy. > > While I agree that we do not want to delay the TLS 1.3 specification > to sort this out; however, I do not think we have provided the hook > to make this future extension easy. Looking at the key schedule in > -19, I think we can provide the hook without being disruptive. My > goal is to minimize the pain to implementing the extension in the > future by putting a straightforward hook in today:
Unless you have fairly good idea about how such extension would look (especially security properties!), I think it is premature to specify where the key will go (if it doesn't go there, you got problems). At least from what I know about my implementation, adding new keys to be injected in present spots is easy (after one has computed the value, it is one method call to inject it). Actually changing what keys are derived from each stage or creating new stages is of course expensive. Currently, there are three stages in key schedule. - 0-RTT (Binders, 0-RTT keys and 0-RTT exporters). - Handshake (handshake keys, finished) - Application (application keys, exporters and dynamic PSKs). In comparision, new handshake message would be far more expensive code-wise, even if I could piggyback main handshake states like with CertificateRequest. And something that actually changes the main state machine would be far more expensive still. And extension specs are only really bound by TLS offer-answer rules. The rest is matter of how difficult the extensions are actually to implement, and how much security problems they have... -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
