Re: [TLS] Refactoring the negotiation syntax

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 13, 2016 at 03:07:46PM -0700, Eric Rescorla wrote:
> On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> 
> 
> >
> > > And then add new code points for being able to use the PSK with and
> > > without signatures (from the server). We had pretty rough consensus in
> > > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01]
> > > is part of the motivation for this idea.
> > >
> > >    enum {
> > >      psk_auth(0),        // PSK only
> > >      psk_sign_auth(1),   // PSK + a signature (as in draft-thomson) [5]
> > >      (255)
> > >    } PskAuthModes;
> >
> > I think that PSK+signature modes are so different that those warrant
> > promotion to a new major key exchange type.
> >
> 
> Hmm...  Why?
 
Or might be better to have those as add-ons like in your proposal. The
above look to be independent.

If you think chinese menus are problematic, coupled choices are way
more so...

> > > 2. One question that comes up at the same time is whether we should
> > > allow multiple key shares to be used, which is a structure that this
> > > makes pretty easy. Basically, the server would just supply as many
> > > counter-shares as it wanted and then we'd need a defined order for how
> > > they were inserted into the key schedule. This feature would be nice
> > > for enabling post-quantum, but probably better to just define
> > > <PQ-Algorithm + Curve> code points.
> >
> > In order of group number? Or in order of server reply?
> >
> > (Both orders would be well-defined). Would also avoid the bit of
> > special case of zero key in pure-PSK mode...
> >
> 
> I was thinking in order of group number, but if you do combined code points
> you don't
> need to do this.

I was thinking of just scanning the server key_share in order the groups
appear... With no mixing if no key_share is absent.

This would unify DHE-PSK and PSK for purposes of later handshake.

Would need a way to ensure that some mixing happened tho!

> 
> > 5. Note: this would allow for modes where the server signs over a PSK
> > > handshake with no DHE at all. The resumption_ctx mechanism is intended
> > > to ensure that that is OK, but we'd need to confirm with analysis.
> >
> > I should also figure out all the attacks I figured out against server
> > auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported
> > any such modes).
> >
> > Yeah, if resumption_ctx stuff is actually used, it should do the trick,
> > as it binds the PSK key used (and the normal handshake hash binds the
> > negotiation).
> >
> > The resumption_ctx would also bind the key if one kept it as constant
> > and omitted Certificate message.
> 
> Definitely like to hear about this.

One thing that comes to mind is (this is not mode that is presently
supported or discussed to be added): Say you had a mode where server
could send a public key in NewSessionTicket and then have client do
key transport with that key to agree "SS key" for 0-RTT and as second
key (useful for PQC purposes, since this lets you use PQEncryption
instead of PQKeyAgreement, and the first seems to be in better shape
than the latter). Now you are in cryptographic weeds and resumption_ctx
won't help.


Also, need to check the extension rules in case of PSKwCERT. More
annoyingly, those depend on the exact semantics of the certificate
authentication in that case.

Certificate is constant (in addition to base ALPN and SNI):
- If status_request was originally present, now status_request or
  status_request_v2 has to be present. Contents can be different.
- server_authz must not be present
- cert_type/server_certificate_type negotiation has to have the same
  result (including the implicit "X509" case)..
- signature_algorithms from client has to contain the signature
  algorithm used on parent connection.
- If status_request_v2 was originally present, it has also be
  present now. Contents can be different.

Key is constant (in addition to ALPN and SNI):
- signature_algorithms from client has to contain the signature
  algorithm used on parent connection.
- If using implcit-key: trusted_ca_keys, status_request,server_authz,
  cert_type,status_request_v2,signed_certificate_timestamp and
  server_certificate_type must not be negotiated.

No constraints (in addition to ALPN and SNI):
- (No additional constraints on extensions)


Each mode from above has its strengths and weaknesses:

Certificate is constant:
- Limits 0-RTT to lifetime of parent certificate (or less!)
+ Revocation works as well as usual (which isn't very!)
- Problems with farms
+- Implicit-key would save chunk of bandwidth, but need to check if it
   is safe (should be, since resumption_ctx covers it)..

Key is constant:
+ 0-RTT lifetime can extend beyond certificate lifetime.
- No workable key revocation.
- Problems with farms
+- Implicit-key would save chunk of bandwidth, but need to check if it
   is safe (should be, since resumption_ctx covers it)..

No constraints:
- Weakest assurances.
- No implicit-key bandwidth savings.



-Ilari