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

[Yaron Sheffer <[e-mail]>]

At ipsecme, we had a few incompatible changes between WG adoption of our 
own chacha draft, and WGLC. So I would recommend against early 
registration altogether.

Thanks,
	Yaron

On 05/20/2015 10:12 AM, Stephen Farrell wrote:
>
> Hi,
>
> While I am generally against ciphersuite proliferation I
> think its a good idea to register some of these now. I
> would note however that you only need the temporary
> registrations for things with which people want to work
> now - any future proofing can be done as the draft
> progresses so the WG do not need to decide all of this
> now. And of course, there is always the potential for
> non-interoperable changes to happen during the WG
> process which is another good reason to not register
> more than the absolute minimum of codepoints now.
>
> So please restrict the early registration list to
> those that are needed *right now*. Anything that can
> wait months, should wait months.
>
> Thanks,
> S.
>
>
> On 20/05/15 07:58, Nikos Mavrogiannopoulos wrote:
>> ----- 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
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls