Subject: [TLS] Salsa20 stream cipher in TLS

From: Simon Josefsson <[email-masked]>
Date: Sun, 17 Mar 2013 23:51:49 +0100

All,

FYI, we have published -00 of a draft that describes how the Salsa20
stream cipher can be added to TLS and DTLS, see:

http://tools.ietf.org/html/draft-josefsson-salsa20-tls

While we are not asking for WG adoption of this draft now, we are at a
point where we would like to invite external review and solicit
feedback.  Some elements of the draft is still in flux.  For example,
initial performance benchmarks suggests HMAC-SHA256 was a poor choice
for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives.
Still, all comments are appreciated.

/Simon

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 18 Mar 2013 19:23:41 +0000

Hi Simon,

On 3/17/13 6:51 PM, "Simon Josefsson" <[email-masked]> wrote:

>feedback.  

Some early feedback; copied CFRG.  It would be good to have review from
that community.

It is not exactly clear what problem is being addressed by this work.
Would be good to add a problem statement section.   In addition, it would
be good to provide the currently-unmet requirements to CAESAR (Competition
for Authenticated Encryption: Security, Applicability, and Robustness)
http://competitions.cr.yp.to/

Some more detailed comments, quoting from the draft:

   Recent attacks has indicated problems with CBC-mode cipher suites in
   TLS/DTLS and problems with the only supported stream cipher (RC4) in
   TLS has been known for a long time.  While AEAD cipher suites address
   these issues, concerns about performance are sometimes raised.

What are the performance concerns?   I suggest citing some relevant
performance data.

  Because the GenericStreamCipher definition in TLS does not provide
   any way to transport the Salsa20 nonce that is required for
   functionality and needed to provide the random access property, we
   let the output from the stream cipher operation be the concatenation
   of the IV and the encrypted data.

Please, define a Salsa20-based AEAD mechanism instead of a new TLS format!

>Some elements of the draft is still in flux.  For example,

If anything other than HMAC-SHA1 is used, that would underscore the value
of defining an AEAD algorithm.   If the main motivation for this work is
encryption that is computationally cheap, then it makes sense to pair the
algorithm with an authentication method with the same characteristics.

For security considerations, I suggest citing the analysis of Salsa20, and
adding a sentence or paragraph summarizing the best-known attacks.
Something like "Salsa20 has been analyzed by X independent teams, and the
best known attack breaks 8 of 20 rounds."

David

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

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 18 Mar 2013 12:48:51 -0700

Hi Simon,

I am interested in this work. I am especially interested in your plan
to allow the salsa20 cipher suites to be used in TLS 1.0 and TLS
1.1, which you stated in the first paragraph of the Introduction
section.

Since all of the new cipher suite names end in _SHA256, I
infer the MAC algorithm is hmac_sha256. (The fact is
not explicitly stated in the -00 draft.) It is important to
clarify how hmac_sha256 can be used in TLS 1.0 and
TLS 1.1, because a naive implementor would see the old
definition of MACAlgorithm in TLS 1.0 and 1.1:

    enum { null, md5, sha } MACAlgorithm;

and conclude that hmac_sha256 can't be used in TLS
1.0 and 1.1.

I'm also interested in figuring out if these cipher suites
can be used in SSL 3.0. The only difficulty I see is
extending the SSL 3.0 MAC algorithm to hash=sha256
(see the definition of the SSL 3.0 MAC in Section 5.2.3.1
of RFC 6101) -- it is not clear what should be the size of
pad_1 and pad_2 for hash=sha256.

The reason I'm interested in SSL 3.0 is that web browsers,
when talking to Google servers, which implement TLS/SSL
version negotiation correctly, are still downgraded to SSL 3.0
by network errors injected by certain network devices.

Wan-Teh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 Mar 2013 21:02:22 +0100

> It is not exactly clear what problem is being addressed by this work.

As I understand, the requirement, is a fast stream cipher that can be
used for TLS and DTLS, and doesn't have the issues RC4 has [0].

[0]. http://home.hiroshima-u.ac.jp/ohigashi/rc4/index.html

> What are the performance concerns?   I suggest citing some relevant

The GCM mode does require special instructions to achieve performance
close (but often not better) to RC4 in general purpose CPUs. The stream
ciphers from the eStream competition outperform RC4 without any hw
assistance.

> Please, define a Salsa20-based AEAD mechanism instead of a new TLS format!

The GenericStreamCipher mode is sufficient for this mode. It just
requires to define how to set the nonce. I think using the AEAD would
complicate things rather than provide any practical advantage.

regards,
Nikos

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 21:42:13 +0100

> Hi Simon,

Hi David.  Thanks for quick review.

> Would be good to add a problem statement section.

Good idea, the document now contains this paragraph:

   The purpose of this document is to provide an alternative stream
   cipher for both TLS and DTLS that is comparable to RC4 in speed on a
   wide range of platforms.

There are other soft factors too.  In general the goal is to offer
something that can replace use of RC4 in TLS.  I'm guessing speed is one
reason people use RC4 in TLS today.

> What are the performance concerns?   I suggest citing some relevant

If there are implementations of this, we can benchmark them and compare
them against other cipher suites and include some numbers or pointers to
comparisons.  I believe Salsa20 is faster than for example AES GCM on
most platforms.

> Please, define a Salsa20-based AEAD mechanism instead of a new TLS format!

That paragraph has been removed from the current work in progress, it
was incorrect (the record sequence number will be used as nonce
instead).  I don't believe the AEAD mechanism works: there is no field
to put the MAC in it.

> algorithm with an authentication method with the same characteristics.

Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a
HMAC-SHA1 variant in the working copy.  It is not clear to me whether
keeping HMAC-SHA256 is useful.

> best known attack breaks 8 of 20 rounds."

Good idea, the first paragraph of the security considerations is now:

   The security of Salsa20 is discussed in the Salsa20 security
   [SALSA20-SECURITY] paper.  The reader must consult cryptographic
   research to find out the current security status of Salsa20.  At the
   time of writing this document, there are no known significant
   security problems with Salsa20/12 or Salsa20/20.  As of early 2013,
   the best cryptanalysis breaks 8 out of 20 rounds to recover the 256-
   bit secret key in 2^251 operations, using 2^31 keystream pairs (see
   [SALSA20-ATTACK]).  For more background, see the eSTREAM report
   [ESTREAM].

/Simon

---

From: Adam Langley <[email-masked]>
Date: Mon, 18 Mar 2013 16:45:51 -0400

> instead).  I don't believe the AEAD mechanism works: there is no field

There's no field for the GHASH tag for AES-GCM either: the
construction of the authentication is opaque to the user of the AEAD
algorithm. If you were to define an AEAD for this then you could
decide where you would like the MAC to know, but it's a property of
the AEAD, not of TLS.

> keeping HMAC-SHA256 is useful.

I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the
typical combination.

Cheers

AGL

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 21:55:38 +0100

Wan-Teh Chang <[email-masked]> writes:

> not explicitly stated in the -00 draft.)

Hi Wan-Teh and thank you for the review.  Good catch, I have added a
paragraph explaining what the MAC algorithm should be.

> It is important to clarify how hmac_sha256 can be used in TLS 1.0 and
> TLS 1.1, because a naive implementor would see the old definition of
> MACAlgorithm in TLS 1.0 and 1.1:
>

Right.

Would adding a set of cipher suites that use HMAC-SHA1 resolve this?  We
have added them already in our working copy for performance reasons.  It
is not clear whether there is any point in also having HMAC-SHA256, it
destroys the performance properties.

> pad_1 and pad_2 for hash=sha256.

I'm hoping that using HMAC-SHA1 here would solve this too, right?

> by network errors injected by certain network devices.

Having compability with SSL 3.0 would be nice.  The next version will
mention SSL 3.0 compatibility too.

/Simon

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 18 Mar 2013 14:01:18 -0700

On Mon, Mar 18, 2013 at 1:55 PM, Simon Josefsson <[email-masked]> wrote:
> have added them already in our working copy for performance reasons.

Yes, using HMAC-SHA1 would solve both of the problems I asked about
(TLS 1.0-1.1 support, and SSL 3.0 MAC compatibility).

If the goal is to provide an alternative to the existing RC4 cipher suites
(most of which use SHA-1), then using HMAC-SHA1 would be the best.

Wan-Teh

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 18 Mar 2013 21:11:57 +0000

Hi Simon,

>instead).  I don't believe the AEAD mechanism works: there is no field

I'm not sure what you mean about the lack of a MAC field.  It would not be
hard to define an AEAD algorithm based on Salsa20; I would be surprised if
there is not a submission to CAESAR using that cipher.  And using the AEAD
in TLSv1.2 is straightforward.   (Is the issue a desire to use Salsa20 in
older versions?)

>   [SALSA20-ATTACK]).  For more background, see the eSTREAM report

Looks good.

David

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 22:17:12 +0100

> decide where you would like the MAC to know, but it's a property of

Right, agreed.  Equally, the content of the ciphertext for a
GenericStreamCipher is opaque to TLS, so we could put a nonce in there
if that was necessary (but we don't need to).  Having stream ciphers
expand data is a bit unorthodox, but from a TLS protocol point of view
it may work.  Some implementation assume there is no message expansion
for stream ciphers, but I haven't seen anything in the specification
that assumes or require that.

> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the

That could be another option.  The only reason is that I haven't worked
with any implementation of Poly1305, so I'm not that familiar with it.

/Simon

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 18 Mar 2013 21:23:54 +0000

Hi Nikos,

>[0]. http://home.hiroshima-u.ac.jp/ohigashi/rc4/index.html

Yes, I'm well aware of the RC4 issues and I support its deprecation.

>ciphers from the eStream competition outperform RC4 without any hw

The appropriate comparison would include both authentication and
encryption, so comparisons to "naked" stream ciphers are misleading.  And
I strongly encourage actual performance comparisons on target platforms.

>complicate things rather than provide any practical advantage.

I respectfully disagree.

David

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 22:47:39 +0100

> in TLSv1.2 is straightforward.   (Is the issue a desire to use Salsa20 in

Yes.  If it is not possible to implement Salsa20 as a
GenericStreamCipher we'll reconsider.  Right now to me it seems Salsa20
is more similar to RC4 than to AES-GCM or other AEAD ciphers and there
is no advantage in specifying it as a GenericAEADCipher while the
advantage for GenericStreamCipher is potential compatibility with older
TLS versions.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 22:49:55 +0100

We pushed out a -01 to address the feedback we got so far.

Refresh the page in your browser if you still see the -00 version.

Thanks,
/Simon

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 Mar 2013 23:42:28 +0100

> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the

We are considering UMAC which is an older MAC, similar to the poly
thing, and already published in RFC4418. Performance-wise UMAC-AES-96
is around 2x the speed of sha1 and 5x the speed of sha256. The small tag
also means more savings in DTLS datagrams which are typically small
(without sacrificing security - remember the finished message MAC is
also 96-bits).

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 19 Mar 2013 08:10:23 +0100

> comparisons.  I believe Salsa20 is faster than for example AES GCM on

Hello,
 I've done some throughput comparisons on my amd64 (no hw acceleration
of AES) and gnutls.

* with a 1400-byte packet size:

RSA_WITH_SALSA20R20_256_UMAC_96: 46.88 MB/sec
RSA_WITH_SALSA20R20_256_SHA1: 40.00 MB/sec
RSA_ARCFOUR_SHA1: 39.34 MB/sec
RSA_ARCFOUR_MD5: 40.35 MB/sec
RSA_AES_128_GCM_SHA256: 29.88 MB/sec

* with a 15360 packet size:

RSA_WITH_SALSA20R20_256_UMAC_96: 59.53 MB/sec
RSA_WITH_SALSA20R20_256_SHA1: 48.66 MB/sec
RSA_ARCFOUR_SHA1: 46.64 MB/sec
RSA_ARCFOUR_MD5: 47.78
RSA_AES_128_GCM_SHA256: 33.64 MB/sec

(the umac-96 is implemented in plain C using the reference code)

regards,
Nikos

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 19 Mar 2013 13:36:06 +0000

Hi Joachim,

On 3/19/13 9:06 AM, "Joachim Strömbergson" <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Aloha!
>
>On 2013-03-18 21:45 , Adam Langley wrote:
>> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is
>> the typical combination.
>
>Is poly1305 widely used?

I think that's the wrong question to ask when considering a MAC based on
universal hashing, since the security of such constructs is well
understood.  

>Would it be advantageous for adoption and
>approval of Salsa20 in TLS to also introduce poly1305?

If one of the motivations for adopting Salsa20 is that it is
computationally cheap (fast in software, small circuit, low power
consumption) then it definitely makes sense to pair it with an
authenticator with the same properties.  It will be important to make sure
that the performance is adequate on all of the processors under
consideration.   Many universal hash functions have a performance that is
closely linked to that of the 32,64, or 128-bit multiplication operation,
which varies widely across CPUs.

>
>My gut feeling is/was that trying to just provide a really good
>alternative to RC4 would be easiest to do and get adoption for.

Well, AES-GCM is certainly a good alternative to RC4 and CBC.  It is
security-conservative, already specified in TLSv1.2 and implemented in
many places, performs very well on dedicated hardware and performs
adequately otherwise, and is approved for use in FIPS-140.

David

>
>- -- 
>Med vänlig hälsning, Yours
>
>Joachim Strömbergson - Alltid i harmonisk svängning.
>========================================================================
> Joachim Strömbergson          Secworks AB          [email-masked]
>========================================================================
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iEYEARECAAYFAlFIYsYACgkQZoPr8HT30QEavwCg04uHLG2XSgTRHt2fL9NZdMft
>FM4AoIlRvzHPPzwnjHe4yKkYOjm9q6Bo
>=ddOd
>-----END PGP SIGNATURE-----

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 19 Mar 2013 14:06:14 +0100

Aloha!

> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is

Is poly1305 widely used? Would it be advantageous for adoption and
approval of Salsa20 in TLS to also introduce poly1305?

- --

---

From: Adam Langley <[email-masked]>
Date: Tue, 19 Mar 2013 11:10:00 -0400

> adequately otherwise, and is approved for use in FIPS-140.

AES-GCM is great on dedicated hardware but, if I may be somewhat
deliberately contradictory :)

On common, low(ish)-end hardware (Cortex A15) Salsa20 is 2x faster
than AES. Additionally, AES and GHASH both use binary fields which, in
order to have an efficient implementation, are often implemented as
table lookups in software. These table lookups cause timing
side-channels[1] and also cache pressure, which isn't accounted for in
benchmarks which run the function in a loop.

(There has been some great work on implementing AES in a side-channel
free manner, and that work is found in OpenSSL and some other places,
but it's very complex and there are lots of much simpler, much more
vulnerable, AES and GHASH implementations out there.)

Salsa20, however, is naturally free of timing side channels. Even a
novice implementation will be secure.

In short, I'm implementing AES-GCM at the moment because we need the
option and there's already a fair amount of deployment. However, I'd
be happy to see a Salsa20 option too. Without it, AES-GCM would be the
only reasonable ciphersuite in TLS for the future.

[1] http://cs.tau.ac.il/~tromer/papers/cache.pdf

Cheers

AGL

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 19 Mar 2013 11:23:39 -0700

> only reasonable ciphersuite in TLS for the future.

Another problem with the AES-GCM cipher suites they can't be used with
older versions of TLS. The most obvious problem is that the GenericAEADCipher
struct is only defined in the TLS 1.2 RFC. (Key expansion also needs to
generate client_write_IV and server_write_IV.)

Although it may be possible to retrofit GenericAEADCipher into TLS 1.0 and
1.1, the existing implementations of the AES-GCM cipher suites restrict them
to TLS 1.2, so there will still be interoperability problems.

Assuming we can solve the problems of using GenericAEADCipher and
updating key expansion in TLS 1.0 and 1.1, new AEAD cipher suites can
describe how they will be used in older versions of TLS from day one.
So it still seems worthwhile to solve the problem of using AEAD cipher
suites in TLS 1.0 and 1.1.

Wan-Teh

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 19 Mar 2013 21:41:16 +0100

> to TLS 1.2, so there will still be interoperability problems.

Implementations could be fixed here, if we want to.  There may still be
interop problems, but there will always be interop problems so
implementations need to handle them anyway.

> suites in TLS 1.0 and 1.1.

That may be useful, and would likely have helped adoption of AEAD
ciphers in TLS if it was done from the start.

I'm not sure why TLS 1.2 isn't negotiated more often by browsers.  If it
is an implementation issue, I'm not convinced specifying AEAD ciphers
for TLS 1.0 and TLS 1.1 will help: they just get another implementation
issue to implement that instead.  Admittedly, it is a different
implementation task, so it may be fixed earlier than the other issue,
but that is difficult to predict.  Generally, it might be better to push
browsers vendors to switch to TLS 1.2 more quickly, then the problem is
also solved.

/Simon

---

From: Jon Callas <[email-masked]>
Date: Tue, 19 Mar 2013 16:30:16 -0700

> browsers vendors to switch to TLS 1.2 more quickly, then the problem is

There are two reasons. Uncertainty about ECC, and uncertainty about GCM.

We can debate how much the ECC uncertainty is warranted, but lots of people have it. We can also debate the GCM issues, but GCM is tetchy to use properly. And yes, you could always use CCM instead. But most people don't know that CCM is part of TLS 1.2. I didn't know it I discovered it while writing this note.

The general opinion about TLS 1.2 is that that's the version for Suite B. That's not precisely true. I had that opinion for a while until I learned I was mistaken. However, if you have concerns about either ECC or GCM, then you have concerns about TLS 1.2. I don't know if you can do 1.2 without ECC or GCM.

	Jon

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 20 Mar 2013 09:02:21 +0200

On 20.3.2013, at 1.30, Jon Callas <[email-masked]> wrote:

>> Generally, it might be better to push

I don't believe I'm alone in this when I think TLS 1.2 and ECC are not related at all, ECC is specified to work on TLS 1.0 or later. And GCM is related only because AEAD is not specified before 1.2, but it is not part of the spec.

> We can debate how much the ECC uncertainty is warranted, but lots of people have it. We can also debate the GCM issues, but GCM is tetchy to use properly. And yes, you could always use CCM instead.…

Well, neither GCM nor CCM are part of TLS 1.2 itself, but both can be used with it as additional cipher suites.

> The general opinion about TLS 1.2 is that that's the version for Suite B. That's not precisely true. I had that

I don't think that's true at all, TLS 1.2 is just a new version of TLS, and Suite B compatibility comes as a nice plus.

> opinion for a while until I learned I was mistaken. However, if you have concerns about either ECC or GCM, then you have concerns about TLS 1.2. I don't know if you can do 1.2 without ECC or GCM.

This was the first time I've heard this kind of comments. 1.2 is just a new version of TLS, and it is perfectly fine to continue using the old TLS 1.0 cipher suites on TLS 1.2 without touching ECC or GCM at all.

I always thought people don't want to implement TLS 1.2 because it brings too many changes that are difficult to test properly (selectable hashes etc). But if someone thinks ECC and GCM/CCM are somehow compulsory, I think that should be clarified.

And personally I think defining AEAD for TLS1.0+ might be a good idea. It would be really easy to implement compared to the full TLS1.2 specification.

Juho

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Wed, 20 Mar 2013 09:55:26 +0000

Hi Jon,

On 3/19/13 7:30 PM, "Jon Callas" <[email-masked]> wrote:

>We can debate how much the ECC uncertainty is warranted, but lots of
>people have it. We can also debate the GCM issues, but GCM is tetchy to
>use properly.
>And yes, you could always use CCM instead. But most people don't know
>that CCM is part of TLS 1.2. I didn't know it I discovered it while
>writing this note.
>
>The general opinion about TLS 1.2 is that that's the version for Suite B.
>That's not precisely true. I had that opinion for a while until I learned
>I was mistaken. However, if you have concerns about either ECC or GCM,
>then you have concerns about TLS 1.2. I don't know if you can do 1.2
>without ECC or GCM.

TLSv1.2 barely mentions either GCM or ECC, much less requires their use.
RFC 5246 says: in the absence of an application profile standard
specifying otherwise, a TLSv1.2-compliant application MUST implement the
cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.  No ECC or GCM ciphersuites are
mentioned in that RFC.  On the flip side, there are benefits in using that
version; v1.2 allows to use SHA256 in key derivation (PRF) and message
authentication (HMAC), allows the use of AEAD, and adds other fixes.

GCM does require a distinct nonce for each encryption operation, which
makes it vulnerable to "nonce misuse", or makes it tetchy as you say.
However, this property is a non-issue in TLS, since it is easy to use a
sequence number as a nonce, and session keys don't persist between
sessions.   For comparison, Salsa20 and UMAC, both recently mentioned on
this thread, would also have exactly the same distinct-nonce requirement,
and essentially RC4 does as well (in the sense that an application that
mis-manages the RC4 state would likely cause a loss of confidentiality).

David

>Version: PGP Universal 3.2.0 (Build 1672)
>Charset: us-ascii
>
>wj8DBQFRSPUpsTedWZOD3gYRAimEAJ0V1eXYxUqRHxWWNaX1GzZJIIz0ZgCfRBXF
>48rWFyQymJ1znyyvWCKO4MY=
>=Jh5v
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: [email-masked] (Martin Rex)
Date: Wed, 20 Mar 2013 18:58:56 +0100 (CET)

> to TLS 1.2, so there will still be interoperability problems.

Technically, it would be simple, sensible and straightforward to
offer AES-GCM for TLSv1.0 and TLSv1.1.

The Definition of the GenericAEADCipher PDU is a non-issue, that'll
work just fine with TLSv1.1 and TLSv1.0.

The most significant problem is the gossip/nonsense in rfc5288 section 4
and rfc6655 section 5; and then there is the desired use of a
SHA-256 PRF (implied by rfc6655, explicit in rfc5288) or SHA-384 PRF
(for the _SHA384 cipher suites in rfc5288).

It is an urban myth that changing the PRF would be easier in TLSv1.2
than it is in TLSv1.0 or TLSv1.1.  There is actually *ZERO* difference.
It is at most unusual to do it in TLSv1.0 and TLSv1.1, because
very few existing cipher suites require it.

Being able to plug-n-play the TLS PRF for specific cipher suites was
already an explicit design goal in TLSv1.0, see:

  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html
  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0230.html

For example: while there is no support for TLS extensions (rfc3546)
in Microsoft Windows SChannel of Windows 2000 and XP, replacing the
PRF in Microsoft SChannel with third-party crypto plugins has always
been possible, see CryptCreateHash() and CryptDeriveKey() functions
and the ALGID parameters CALG_TLS1_MASTER, CALG_SCHANNEL_*,
which were already defined in the Visual Studio 98 "wincrypt.h"
header file from 23-Apr-1998.

There exist third-party plugins that provide TLS GOST cipher suites
for use with Microsoft SChannel (and therefore all of its callers,
such as MSIE) on Windows 2000&XP, and they change all relevant things
--TLS PRF, asymmetric, symmetric and hash algs, the contents of
the KexExchange and "digitally signed struct", as well as the
content of the "Finished" handshake messages.

> suites in TLS 1.0 and 1.1.

My personal problem with TLSv1.2 (which causes me to completely ignore it)
is the fouled up "SignatureAlgorithms" extensions and the braindead
semantics rfc5246 defines how that flawed extension is supposed to interfere
with signatures on certificates.  The way it is currently defined, TLSv1.2
interferes VERY BADLY with interop of scenarios that work just fine with
TLSv1.0 and TLSv1.1.  It is also currently impossible to support
GOST cipher suites _and_ offer TLSv1.2 (whereas GOST works just fine
with TLSv1.0 and TLSv1.1).

-Martin

---

From: Jon Callas <[email-masked]>
Date: Wed, 20 Mar 2013 16:53:55 -0700

> mis-manages the RC4 state would likely cause a loss of confidentiality).

I apologize for note being organized in my typing. Let me try again.

Rightly or wrongly, there's a perception both on the implementation end and the deployment end that TLS 1.2 is the "Suite B" version of TLS, that it's mandatory to implement and mandatory to deploy. That this is a misperception is in fact what part of the problem is. I've held many of these misperceptions myself, and if someone as expert as I doesn't grok TLS 1.2, then how is the average developer or sysadmin going to understand?

TLS 1.2 needs some marketing that explains why people want it, and that needs to include reassurance that it doesn't require you to commit to ECC and GCM. Many people out there believe precisely this.

	Jon

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 Mar 2013 20:04:46 -0400

> TLS 1.2 needs some marketing that explains why people want it, and that needs to include reassurance that it doesn't require you to commit to ECC and GCM. Many people out there believe precisely th…

I believe that the reason that TLS 1.2 hasn't seen wider deployment is
that it causes compatibility issues and the motivation hasn't
previously been strong enough.

Microsoft, for example, have had TLS 1.2 support in SChannel for a
while, but IE doesn't send TLS 1.2 ClientHellos because they break
some sites. When Chrome enabled TLS 1.1 support, we had to add a
fairly promiscuous fallback to TLS 1.0 (on top of the fallback to
SSLv3) to address these problems.

NSS doesn't have TLS 1.2 support (yet; it's coming) because there are,
in general, more people talking about TLS than working on the
underlying libraries :) Those that do have many other things that they
can be working on and spending time on TLS 1.2 support hasn't had the
best cost/benefit tradeoff yet.

I don't think that ECC or GCM fear plays a part. There may be people
who have that fear, but I don't think they are deciding, for the most
part, what gets implemented in browsers and many servers. (And, as
noted, the ECC part is nonsense: Google has been using ECDHE with TLS
1.0, 1.1 and 1.2 for a while now.)

Cheers

AGL