Subject: [TLS] draft-modadugu-tls-ctr-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Oct 2005 13:34:53 -0700

Relatively soon you should see an announcement about 
draft-modadugu-tls-ctr
(temporary location: http://www.dial911anddie.com/dtls/tlsctr.txt)

This draft specifies AES Counter Mode for TLS and DTLS. 
Comments welcome! One prefatory note: this mode was designed
specifically to be essentially the same in TLS and DTLS, which
is why it doesn't behave exactly like RC4.

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Jack Lloyd <[email-masked]>
Date: Mon, 17 Oct 2005 17:12:43 -0400

I can't say I'm a huge fan of the IV generation method, as it
basically means a TLS implementation has to treat block ciphers in CBC
mode, block ciphers in CTR mode, and stream ciphers all in different
ways. While saving the per-record IV is, I suppose, nice, the extra
code complexity doesn't make it a worthwhile tradeoff (IMO); you could
do counter mode using either the explicit IVs in TLS 1.1 or even using
an implicit counter when using TLS 1.0 (starting with the originally
negotiated IV and incrementing), and save a lot of trouble. And IIRC
DTLS always uses explicit IVs right now, so there is no problem
there. Is there some environment where saving the IV (and padding
bytes, if you were to treat CTR mode as "exactly like CBC, but
better") is actually enough of a win where that is worth the effort?

Secondly, it would be nice if this was just slightly more general, to
allow the use of other block ciphers. While it would still be
necessary to produce an RFC with the ciphersuite numbers, etc, there
is no reason the method adopted should not be directly usable with
other ciphers. In particular, I note that the IV generation method as
it is defined now will only work with 128-bit block ciphers. As far as
I know, 3DES in counter mode is perfectly secure (and is FIPS approved
until at least 2010), and might be a good choice if, for example, you
have a 3DES hardware encryptor handy, or if you just don't trust AES
for whatever reason. I don't see the point in designing the mechanism
specifically to exclude it, unless we're going with a "thy block
cipher is AES and thou shalt have no block ciphers before it"
interpretation. Which might be reasonable; I'd just like to see a
little discussion on it beforehand.

-Jack

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 18 Oct 2005 10:45:26 +0200

> is why it doesn't behave exactly like RC4.

My main concern would be why this extra block cipher mode might be needed. It 
seems that given that this stream mode is based on a block cipher it offers 
little advantage over cbc for hardware implementors. Also the fact that 
random size padding is not available it makes it inferior to TLS CBC mode for 
the purposes of traffic analysis. Don't take it negatively, but the main 
issue that this cipher mode solves, wasn't clear to me from the document.

-- 
Nikos Mavrogiannopoulos

-- 
Nikos Mavrogiannopoulos

---

From: Michael Bowler <[email-masked]>
Date: Tue, 18 Oct 2005 08:48:05 -0400

> little advantage over cbc for hardware implementors.

Counter mode may be pipelined, alowing very fast hardware 
implementations.  Unfortunately, combining a potentially fast counter 
cipher with a slow authenticator (HMAC-SHA1) reduces this benefit.

Michael

-- 
Michael Bowler                                [email-masked]
IC Design Engineer                                  (613) 254-5456x107
Elliptic Semiconductor                            www.ellipticsemi.com

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2005 06:24:49 -0700

> better") is actually enough of a win where that is worth the effort?

Well, applying CTR to DTLS means that you really need to be able to
reset the cipher-state on a per-record boundary, whether the IV is
explicit or implicit. This rules out the "long cipher stream" approach
that TLS uses for RC4, at least for DTLS. Obviously, you could use
different mechanisms for TLS and DTLS, but this introduces extra
complexity. If we agree that we want the mechanisms to be the same
between TLS and DTLS, then this forces block, stream, and CTR all to
be different in TLS.

This brings us to the question of IV. Once you're resetting the state
at the record boundary, it's not clear to me that an explicit IV is
substantially more complicated than an implicit one, and the
additional 16 octets on the wire is not insignificant, esp.  seeing as
a major part of the rationale for CTR is to reduce transmission
bandwidth. This does seem to me to be important in some environments,
esp. VPNs (if small packet sizes are used) and voice.

> little discussion on it beforehand.

Well, I think there are two separable issues here: whether we should
support ciphers other than AES and whether we should support ciphers
with block sizes < 128 bits. In general, I tend to think we should
be moving away from DES, so I'm not super-eager to try to accomodate
it. I agree that it would make sense to generalize this mechanism
to block sizes > 128 bits.

-Ekr

---

From: nagendra modadugu <[email-masked]>
Date: Wed, 19 Oct 2005 09:36:55 -0700

> issue that this cipher mode solves, wasn't clear to me from the document.

Agreed that CTR mode provides less protection against traffic analysis--
however, there are a number of applications that send fixed sized or
predictable size packets anyway (voice in particular, but even VPNs and
Web traffic generate fairly predictable packet sizes in many situations)
In such cases, CBC does not offer much protection against traffic
analysis.

The main point that CTR mode addresses is low-bandwidth that results
from saving on explicit-IV and the padding block (between 17-32 bytes
total), which can be a significant overhead for applications that
generate small records (such as voice and VPN.)  I'll work on making
this point more prominently in the draft.  Thanks,

nagendra