On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara <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> >> > 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? > Yes, while preserving the ability to add it later by adding a PskAuthMode extension parallel to this one. -Ekr > > 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
