On Fri, Oct 07, 2016 at 01:41:48PM -0700, Eric Rescorla wrote:
> 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.

But unlike the KexMode extension, the AuthMode one would not be
mandatory if PSK extension is included (the KexMode extension has no
sane defaults!).

And the semantics of authentication with PSK are much more subtle than
semantics of key exchange with PSK.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to