Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls

[Nikos Mavrogiannopoulos <[e-mail]>]

----- Original Message -----
> I tend to agree.  Can someone reply with a brief explanation of why
> each of the following is needed?  Hopefully better than what I was
> able to devise:

I don't think one would have to explain each and every usage
of a ciphersuite. If applications don't need it they won't use it. 

> TLS_RSA_WITH_CHACHA20_POLY1305
> Because we're scared of ephemeral key exchange for some reason ?

I believe the main argument is that this draft is supposed to provide 
ciphersuites to used by existing protocols and applications which already 
use RSA. Yes, I agree that some of them would need to be updated to provide 
PFS, but this draft doesn't update those apps/protocols. A protocol that
I know that relies on the RSA ciphersuites is the anyconnect vpn protocol
(even though its usage doesn't affect PFS).

> TLS_DHE_PSK_WITH_CHACHA20_POLY1305
> Because ECDHE is nice, but we need a backup, even for little things ?

That was my intention. To provide DHE as backup to ECDHE, since they 
are not susceptible to the same attacks.  It is now
especially relevant since we will have fixed groups for DHE.

> TLS_RSA_PSK_WITH_CHACHA20_POLY1305
> Because little things like doing bignum exponentiation without any PFS
> payoff, but RSA alone isn't "secure enough" ?

I don't have much data for this ciphersuite. If someone has a strong argument
on why it shouldn't be included I wouldn't object.

> The thing that concerns me most is that we aren't saying that PFS is
> required outside of PSK.  I understand the carve-out we've made for
> the little things, but I don't understand why we are defining
> RSA-based suites without PFS.

I agree. However, note that this draft is not the place to argue for that,
but rather the protocols that rely on non-PFS ciphersuites.

> Of comparable concern is the RSA_PSK stuff.  I wasn't around for the
> definition of these originally, but they make basically no sense to
> me.

The idea was to provide both certificate auth for the server and PSK
auth for the client. The implementation was less than ideal.

> Also, I'm not against DHE in general, and I think that it's worth
> keeping around for a little longer. However.  If we consider DHE_RSA
> worth doing, then the only logic I can concoct would provide almost
> equal justification for DHE_ECDSA.

There is no DHE_ECDSA key exchange defined for TLS. Otherwise there would
be no reason for these ciphersuites to be there.
 
regards,
Nikos