On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > <ilariliusva...@welho.com <mailto:ilariliusva...@welho.com>> wrote: > > On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara > <ilariliusva...@welho.com <mailto:ilariliusva...@welho.com>> > > wrote: > > > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > > 4. I've taken a suggestion from David Benjamin to move the > negotiation > > > > of the PSK key exchange parameters out of the PSK itself and > into a > > > > separate message. This cleans things up and also lets us > drop the > > > > currently non-useful auth_mode parameter. > > > > > > Eeh... From the text, it seems to currently require the kex modes > > > extension if PSK extension is present. Which seems worse than > useless > > > if the meaning is to get rid of the kex mode parameter from PSK > > > extension (since you will have the value anyway, but need to > dig it > > > from another extension... Blech). > > > > I guess this is a matter of taste, but what convinced me was that: > > > > 1. It put all the logic on the server side. >
I was going to ask whether this also includes the decision on whether to send a Certificate to authenticate the server (even for PSK modes), but it looks like this change is intentionally removing the ability to do PSK keyex and auth with a certificate? > > 2. It removed the auth mod parameter. > > > > Maybe david can say more. > > I mean if server is to accept PSK, it must now go fishing for another > extension, check that it is present and pay attention to values there. > As opposed to having the data in where it is needed. > > > This is a reasonable argument (and the reason I stuffed the binder here). > However, David's argument was that this applied to *all* PSKs even new > ones. > Implementations already have to do some amount of "scan through all extensions to detect certain things, do some initial processing, and then finish process everything [else]", not least because SNI can change what cert types you have, configuration knobs, etc.. So, yes it's bad, but how bad is it in a relative sense? I think there is some value in the client indicating to the server whether it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future NSTs, though it's perhaps not of the utmost importance. That property does support a separate psk_key_exchange_modes extension in preference to rolling it into pre_shared_keys (as a separate list next to identities and binders), but it seems to only be a weak argument for separation. I do think that keeping the psk kex mode orthogonal to the individual keys is helpful, though. Anyway, maybe it's time to bite the bullet and actually write up the description of the proper procedure for ClientHello processing (scan extensions for SNI, load up servername-specific config+cert/key, etc.). Which would make this stuff any prettier, but would at least help people not get it wrong. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
