Subject: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Mar 2016 19:41:58 +0000

Hiya,

This is ready to go but I've one question. Sorry I don't
recall if this was discussed previously, if it was, then
just say and I'll move this along to IETF LC.

My question is: Should the WG take the opportunity to more
tightly define the key exchange parameters for these
ciphersuites?

For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could
REQUIRE RSA keys with >=2048 bit moduli and one could go
further and say that this also REQUIRES use of specific
integer DH groups. Etc etc.  Getting all that agreed might
take a wee while, so if the answer is "nah, no thanks, we don't
want to do that here," that's fine and I'll just start IETF
LC.  I guess another way to handle that might be to say that
these ciphersuites REQUIRE that all relevant restrictions
from BCP195 be enforced. That'd maybe ensure the public key
stuff is all at good strength, but doing so might not be so
effective, in terms of trying to ensure these ciphersuites
aren't used with e.g. short RSA keys.

Whatchacha think?

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Mar 2016 20:12:29 +0000

On Thu, Mar 10, 2016 at 07:41:58PM +0000, Stephen Farrell wrote:

> integer DH groups.

I think that enforcing such a requirement for just new cipher-suites
would be counterproductive.

If a server has a 1024-bit RSA certificate or is configured with
1024-bit DH parameters, should it not offer CHACHA20, and restrict
the client to AES or 3DES which don't have that contraint?  What
does that achieve?  Or should the server go ahead with CHACHA20
and then the client refuse?

I think it makes more sense to set such floors on a per-protocol
basis (TLS 1.3, ...) than a per-cipher-suite basis.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 10 Mar 2016 16:02:53 -0500

On Thursday, March 10, 2016 02:41:58 pm Stephen Farrell wrote:
> integer DH groups. Etc etc.

This is a good idea that I think is likely to be impractical and could greatly hurt adoption, at least with regard to RSA. Requiring only secure (EC)DHE groups, however, I think is probably worth consideration. Both could be dealt with in a single TLS stack update, but requiring better certs is still a pain for entirely too many (hopefully this won't be true for that much longer).

Dave

---

From: Yoav Nir <[email-masked]>
Date: Fri, 11 Mar 2016 00:19:41 +0200

I agree with Viktor and Dave.

RSA with keys greater at least 2048 bit is a good requirement that can be made of old and new implementations. Even if for some reason you’re stuck with OpenSSL 0.9.6 and thus with TLS 1.0 and 3DES, you can conform to this requirement. I think it would be a shame to make that requirement only of implementations while they’re using ChaCha.

And yes, there’s nothing more wrong with using ChaCha with 1024-bit RSA then there is with using AES with it.

Yoav

> On 10 Mar 2016, at 9:41 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Mar 2016 10:06:15 +0000

Hiya,

> tightly define the key exchange parameters for these

Since it seems nobody liked that suggestion, I've asked for
IETF last call to be started on the doucment as-is.

Cheers,
S.