Re: [TLS] DSA should die

I think I would prefer to break things up between what is needed for the
record protection and what is needed for authentication (of the peer).
The argument has been made on other threads on the list that these are two
separate concerns and I think it would be best to treat each one as a
unit.  I think TLS 1.3 will make this separation a bit more formal
especially with the removal of RSA key transport.

The record layer protection aspect would include things directly involved
in generating and using the encryption keys:

      AEAD Cipher (e.g. AES-GCM) +  Key agreement (e.g. DH)  + KDF/PRF
(HKDF-SHA256)

I'm tempted to throw the groups used in the DH agreement (25519, p-256,etc)
because that way you can make sure you are consistent matching your
algorithm strength between key agreement and encryption.   I could also see
negotiating the group separately to contain the combinatorial possibilities
of allocations, although we may want to warn against some combinations
 It might make sense to tie the KDF into Key agreement and perhaps these
are fixed to the TLS version.

Authentication would include what the handshake uses use for authenticating
the peers.   It seems there are a number of parameters here: signature
algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), certification parameters (cert
types and params), handshake hash (maybe this is set by the KDF above).
The parameterization of authentication mechanisms may be a bit more
complex, but I think we have much of the machinery there already, it just
may need to be tweaked a bit.

Joe

On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett <davemgarrett@gmail.com> wrote:

> On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote:
> > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos <codesinchaos@gmail.com>
> wrote:
> > > I think full a-la-carte is too complex. But I'm for negotiating the
> > > handshake and symmetric crypto separately. They're already very
> > > loosely coupled and most proposals that introduce/obsolete
> > > ciphersuites are only interested in one of the two sides, with the
> > > other being only an afterthought.
> >
> > That would be a huge improvement over what we have now.
>
> That could be a good middle ground. Just split cipher suites into
> essentially asymmetric & symmetric cipher suites, and put them both in the
> same array. Server just picks one of each for handshake & connection.
>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>