Subject: [TLS] TLS1.2 vs TLS1.0

From: Ulrich Herberg <[email-masked]>
Date: Mon, 20 May 2013 13:47:08 -0700

Hi,

I have not followed this WG, so please forgive me if a similar
question has already been discussed.

I am participating in another SDO on a standard for automated Demand
Response, called OpenADR (www.openadr.org), an application for the
smart grid. The application is basically a web service, exchanging XML
over HTTP over public networks, and using TLS (with RSA and ECDSA /
SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft
allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires
vendors to provide a migration plan in case TLS1.0 is obsoleted) .
TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure
about the best current practice. Is it absolutely discouraged to use
them? The argument in the OpenADR alliance is that many libraries and
programming languages do not support TLS1.2, so they recommend to
start the handshake with 1.2 and then downgrade - if required - to
1.0. I read that NIST disallows SHA1 after 2013; which would also
affect TLS1.0, which does not support SHA2.

What would be your recommendation in this case? Mandate TLS1.2 and
disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2
and SHA2 ciphers, and otherwise to use TLS1.0?

Best regards
Ulrich

---

From: Paul Duffy <[email-masked]>
Date: Mon, 20 May 2013 17:43:44 -0400

Hi Ulrich

IMO mandate TLS 1.2 (as SEP2 did).

For all of the reasons you mentioned below.

With OpenADR, we are talking about an app that impacts the electric grid.

Cheers

On 5/20/2013 4:47 PM, Ulrich Herberg wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 May 2013 08:05:20 +0100

+1. TLS 1.2 also opens up use of the AEAD ciphers.

Robert

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 21 May 2013 10:12:21 +0200

>From a practical perspective using this suggestion implementers are
expected to support 3 protocols. TLS 1.0, TLS 1.1 and TLS 1.2. Except
from the fact that this requires more code, given the
incompatibilities we see on the web between implementations, the
implementations of your protocol may end-up only using TLS 1.0.

> them?

There are known issues in TLS 1.0 which have been fixed in later
versions (the issues in CBC ciphersuites comes to mind, there may be
more). Moreover TLS 1.0 and 1.1 only support the RC4 and CBC
ciphersuites, and there are known attacks on both (which may affect
your protocol or not).

> The argument in the OpenADR alliance is that many libraries and
> programming languages do not support TLS1.2,

Many also do.

> and SHA2 ciphers, and otherwise to use TLS1.0?

If what you specify is something new, IMO, there are not many reasons
to allow legacy protocols.

regards,
Nikos

---

From: Hanno Böck <[email-masked]>
Date: Tue, 21 May 2013 10:26:47 +0200

On Mon, 20 May 2013 13:47:08 -0700

> and SHA2 ciphers, and otherwise to use TLS1.0?

The biggest security issue with TLS 1.0/1.1 is less the use of sha1 and
more the use of CBC+hmac in a very wacky combination.
From what I'm aware, the use of SHA1 in HMAC shouldn't affect its
security. Still it's a good idea to avoid sha1 - it just isn't the most
pressing security issue.

You should definitely require TLS 1.2 and avoid CBC-ciphersuites if
possible if you want high security. The AEAD-ciphersuites (i.e.
everything with AES-GCM) in TLS 1.2 are the thing you want to use.

The issue with libraries not supporting TLS 1.2 isn't as severe as it
may seem. OpenSSL supports TLS 1.2 since a while, GnuTLS also does,
the MS-provided ssl libs since Windows 7 as well. nss has no support
yet, but there are experimental patches and it's expected to come quite
soon. So unless you have a very strong need to use outdated versions of
crypto libraries (which is generally not a good idea), it shouldn't be
much of an issue.

cu,
-- 
Hanno Böck		mail/jabber: [email-masked]
GPG: BBB51E42		http://www.hboeck.de/

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 21 May 2013 11:05:33 +0000

+1 to what Hanno said.

David

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 May 2013 15:47:42 +0200 (CEST)

Ulrich Herberg wrote:
> vendors to provide a migration plan in case TLS1.0 is obsoleted).
> about the best current practice.

Please ignore the "obsolete" tagging on rfc2246 and rfc4346, they're
formally provable clerical errors.

The IETF "obsoleted" tag is about documents obsoleting each other,
and that has not happened.

>
> Is it absolutely discouraged to use them?

Just the opposite.  TLSv1.0 and TLSv1.1 are still perfectly fine for use,
and TLSv1.2 itself has a number of open problems, beside a poor track
record of backwards interop.

The alleged (confidentiality) problems that have been demonstrated so far
are about design-flawed communication peers that require an attacker
to be able to insert data into the beginning of the TLS-protected
communication an repeat the request a few thousand times (or more)
in order to perform plaintext recovery on allegedley confidential
data that the attacked communication peer willingly inserted into
the same TLS channel following the data provided by the attacker.

This problem primarily affects Web Browsers, which essentially are
huge security design-flaws by themselves, and to some extent
VPNs that multiplex data from different sources over a single
TLS-protected communication channel.

Datagram TLS (DTLS) is another can of worms, because it has an unreasonable
requirement to ignore unlimited amounts of MAC-failing DTLS records on a
DTLS connection, but that is a defect from which the stream-oriented
regular TLS protocols do not suffer.

-Martin

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 21 May 2013 14:01:11 +0000

Hi

> the same TLS channel following the data provided by the attacker.

This is an incorrect representation of the known attacks on confidentiality (as I understand them, at least).

- The attacker-injected data does not have to be at the start of the TLS-protected communication.
- The peer-inserted data does not have to follow the attacker-provided data.

> regular TLS protocols do not suffer.

True. Though the spec for DTLS does allow DTLS implementations to terminate a connection in the event of errors. 

It's just that most (all?) implementations don't.

Cheers!

Kenny

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 May 2013 16:37:10 +0200 (CEST)

Paterson, Kenny wrote:
> This is an incorrect representation of the known attacks on
> confidentiality (as I understand them, at least).
> 

True.  Technically, attacks (on CBC) become possible whenever the attacker
can force data of his choice to be processed along with a block of unknown
data under the same block cipher key and observe differences in the
resulting behaviour.

Being able to insert plaintext before the unknown data can be used to
attack the senders encryption oracle (what BEAST did), which may allow
blackholing the resulting output in order to avoid alarm bells
going off on the peer (original receiver).

For the more generic attacks on CBC-Padding using the receivers decryption
oracle it would be sufficient if the attacker can entice the client to
repeat essentially the same request (i.e. with the same interesting data
at a known or predictable position) sufficiently often (typically a few
thousand to a few million times), then rearranging the network data
that the receiver is going to process will be sufficient.  The large
number of failed reciever-side processing might eventually set off
receiver-side alarm-bells.

> True. Though the spec for DTLS does allow DTLS implementations to
> terminate a connection in the event of errors. 
> 

Now that you mention it, I hadn't noticed that DTLS gives actual two
_different_ guidances (MAY abort on MAC error and MUST discard records
with MAC error are mutually exclusive)

http://tools.ietf.org/html/rfc4347#section-4.1.2.1

   4.1.2.1  MAC  (last paragraph):

   In general, DTLS implementations SHOULD silently discard data with
   bad MACs.  If a DTLS implementation chooses to generate an alert when
   it receives a message with an invalid MAC, it MUST generate
   bad_record_mac alert with level fatal and terminate its connection
   state.

http://tools.ietf.org/html/rfc4347#section-4.1.2.5

   4.1.2.5  Anti-replay  (last paragraph):

   If the received record falls within the window and is new, or if the
   packet is to the right of the window, then the receiver proceeds to
   MAC verification.  If the MAC validation fails, the receiver MUST
   discard the received record as invalid.  The receive window is
   updated only if the MAC verification succeeds.

-Martin

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 21 May 2013 09:25:53 -0700

Thank you very much for the comments so far. This is a useful
discussion, and I pointed the OpenADR alliance to this conversation.

Ulrich

---

From: Xiaoyong Wu <[email-masked]>
Date: Tue, 21 May 2013 17:16:20 +0000

>From a practical point of view, terminating on MAC error is prone to a simple attack, especially on IPv4 network. An attacker would only need to forge a UDP packet to either the client/server to get the connection terminated.

-Xiaoyong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paterson, Kenny
> Sent: Tuesday, May 21, 2013 7:01 AM
> To: [email-masked]
> Subject: Re: [TLS] TLS1.2 vs TLS1.0
> 
> Hi
> 
> > The alleged (confidentiality) problems that have been demonstrated so
> > far are about design-flawed communication peers that require an
> > attacker to be able to insert data into the beginning of the
> > TLS-protected communication an repeat the request a few thousand times
> > (or more) in order to perform plaintext recovery on allegedley
> > confidential data that the attacked communication peer willingly
> > inserted into the same TLS channel following the data provided by the
> attacker.
> 
> > Datagram TLS (DTLS) is another can of worms, because it has an
> > unreasonable requirement to ignore unlimited amounts of MAC-failing
> > DTLS records on a DTLS connection, but that is a defect from which the
> > stream-oriented regular TLS protocols do not suffer.
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 May 2013 15:42:27 -0700

On Tue, May 21, 2013 at 7:37 AM, Martin Rex <[email-masked]> wrote:

> unreasonable

Hmm.... I'm not sure these are contradictory.

If you get a packet with a MAC error you MUST discard the packet (i.e.,
not process it.) You may either *silently* discard it (i.e.., proceed as if
you had not received it) or terminate the connection with an alert.

-Ekr

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 21 May 2013 16:45:14 -0700

Hi Hanno,

thank you for the recommendations. Please see below:

On Tue, May 21, 2013 at 1:26 AM, Hanno Böck <[email-masked]> wrote:
[...]
> everything with AES-GCM) in TLS 1.2 are the thing you want to use.

I see. Are the CBC ciphersuites considered unsecure? I have found the
following paper that seems to claim that there are possible attacks:
http://www.isg.rhul.ac.uk/tls/TLStiming.pdf
And a draft with an alternative (claiming that AEAD has performance issues):
http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02

Was that discussed in this WG?

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 21 May 2013 17:13:25 -0700

P.S. I see that the draft I mentioned has been discussed on the mailing list.

Is there any recommendation in which cases the use of CBC ciphersuites
would actually cause any (practical) risk so that we can evaluate
whether we should use alternatives to CBC like AEAD? Is current
support for AEAD cipher suites in common TLS1.2 implementations as
good as for CBC cipher suites? Is there any drawback for using AEAD
ciphers? Is there any sort of best practice or similar document where
a user designing an application can make a choice which TLS version /
cipher suites to use? Currently, the OpenADR protocol mandates to use:

for TLS1.0 (only if a device does not support higher versions of TLS):
ECC – TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
RSA – TLS_RSA_WITH_AES_128_CBC_SHA

for TLS1.2 (default):
ECC – TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
RSA – TLS_RSA_WITH_AES_128_CBC_SHA256

The messages that are exchanged are XML documents within HTTP POST.

Thanks
Ulrich

On Tue, May 21, 2013 at 4:45 PM, Ulrich Herberg <[email-masked]> wrote:
[...]

---

From: Geoffrey Keating <[email-masked]>
Date: 21 May 2013 17:38:19 -0700

Ulrich Herberg <[email-masked]> writes:

> whether we should use alternatives to CBC like AEAD?

I believe you'd need to very carefully evaluate the entire system you
would plan to use the CBC ciphersuites for applicability of known
attacks such as:

- The issue fixed in TLS 1.1, use of a predictable IV
- The timing issue(s) discussed in the "Lucky Thirteen" paper
- Information disclosure due to use of compression

Each of these may or may not apply to a particular system or
implementation.  For example, timing issues can be a big problem if
you have small embedded devices---or no problem at all because
communication always happens at particular scheduled times and the
messages are prepared earlier.

> Is current support for AEAD cipher suites in common TLS1.2
> implementations as good as for CBC cipher suites?

No, alas.  But it's pretty good and getting better.

> Is there any drawback for using AEAD ciphers?

Not that I know of.

> Is there any sort of best practice or similar document where
> cipher suites to use?

I think any situation that forces you to use earlier versions of TLS
or cipher suites that aren't AEAD is pushing you out of "best
practice" and into the jungle of "whatever needs to happen to make this
work".

---

From: [email-masked] (Martin Rex)
Date: Thu, 23 May 2013 00:52:25 +0200 (CEST)

> - The issue fixed in TLS 1.1, use of a predictable IV

Which matters only when you let the attacker provide plaintext that
is encrypted along with information that the attacker is not supposed
to know, and let the attacker retry this guessing game with the
same unknown information often enough.  Can be mitigated with
1/(n-1) record splitting.  See e.g. http://www.educatedguesswork.org/comsec/

> - The timing issue(s) discussed in the "Lucky Thirteen" paper

... which affects CBC cipher suites in  TLSv1.1 and TLSv1.2 as well.

and was previously dicussed _and_ solved in Serge Vaudenay's 2001 paper,
however for some mysterious reason, Serge's recommendation didn't make
it into the 2006 TLSv1.1 or 2008 TLSv1.2 updates... (section 6.5)

 http://infoscience.epfl.ch/record/52417/files/IC_TECH_REPORT_200150.pdf

> - Information disclosure due to use of compression

Which affects *ALL* cipher suites (including AEAD) in all TLS protocol
versions, and was pointed out clearly in the Wagner&Schneier 1996
SSLv3.0 Protocol Analysis (Section 3.2):

 http://www.schneier.com/paper-ssl.html

> messages are prepared earlier.

Whether "timing" provides an attack surface depends on several factors.
Timing may enable a decryption oracle when either there are variations
in processing dependent on low-entropy crypto padding (such as CBC-padding
for symmetric block ciphers (Vaudenay) or padding schemes used by
assymetric crypto private key operations, e.g. PKCS#1 v1.5 padding
for RSA key exchange (Bleichenbacher) as used by TLS.

> No, alas.  But it's pretty good and getting better.

The arbitrary (and totally needless) decision to limit AES-CCM & AES-GCM
ciphersuites to TLSv1.2 is significantly slowing its adoption.

> > Is there any drawback for using AEAD ciphers?

It should be glaring obvious that the integrity protection will be
cryptographically weaker than with any reasonable HMAC scheme (just
by comparing the size of the internal state of the algorithms).

But it seems to be "good enough" (strong enough) for a number of folks.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 23 May 2013 02:51:45 +0200 (CEST)

Eric Rescorla wrote:
> Martin Rex <[email-masked]> wrote:
> >
> > Paterson, Kenny wrote:
> > >

Silently discarding it     = proceed as if you had not received it

non-silently discarding it = log an error and proceed as if you had not
                             not received it

Terminating the connection with an alert means "processing it".

So yes, there is a contradiction.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 23 May 2013 03:20:22 +0200 (CEST)

> So yes, there is a contradiction.

For comparison, look at the more elaborate discussion in the successor
DTLS document:
  http://tools.ietf.org/html/rfc6347#section-4.1.2.7

   4.1.2.7.  Handling Invalid Records

   Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
   invalid formatting, length, MAC, etc.).  In general, invalid records
   SHOULD be silently discarded, thus preserving the association;
   however, an error MAY be logged for diagnostic purposes.
   Implementations which choose to generate an alert instead, MUST
   generate fatal level alerts to avoid attacks where the attacker
   repeatedly probes the implementation to see how it responds to
   various types of error.

Where you can see the two variants of discarding ("silently" and logging
an error) that preserves the association, and the behaviour
"Implementations which choose to generate an alert instead", being
explicitly characterized as distinct to discarding.

btw. there is another contradiction within rfc4347 section 4.1.2.1 MAC
between paragraph 3 and 4 (which is reproduced in rfc6347):

   http://tools.ietf.org/html/rfc4347#section-4.1.2.1
   http://tools.ietf.org/html/rfc6347#section-4.1.2.1

   Note that one important difference between DTLS and TLS MAC handling
   is that in TLS MAC errors must result in connection termination.  In
   DTLS, the receiving implementation MAY simply discard the offending
   record and continue with the connection.  This change is possible
   because DTLS records are not dependent on each other in the way that
   TLS records are.

Paragraph 3 says "MAY simply discard the offending record and continue
with the connection", whereas paragraph 4 says "DTLS implementations
SHOULD silently discard data with bad MACs.".

You can not use two distinct imperatives (MAY and SHOULD) for the
very same behaviour, that is a contradiction.  You can only use one
or the other.

Maybe the document (co-)authors should be using the "MAY WISH TO"
http://tools.ietf.org/html/rfc6919#section-6 keyword instead
of the rfc2119 SHOULD in paragraph 4 of rfc4347 section 4.1.2.1.  ;-)

There are some folks in the IETF security area (in particular over
at PKIX) that feel very strongly about SHOULDs.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 May 2013 18:29:55 -0700

> Terminating the connection with an alert means "processing it".

Unsurprisingly, I don't agree with this interpretation.

-Ekr

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 23 May 2013 19:18:16 +0000

There is no contradiction - in both sections a record with a bad MAC MUST be discarded.

4.1.2.1 specifies two subcases of discarding: do nothing else (silently discard) or discard then alert/terminate).  Those subcases do not conflict with 4.1.2.5.

I disagree with the SHOULD in 4.1.2.1, because that says the IETF disapproves of generating fatal alerts.  Unless there is good justification for saying applications SHOULD NOT alert and terminate, the SHOULD should be MAY.

Logging is independent of processing, not a third alternative.  Silently discard (with or without logging) is one processing action, and alert and terminate (with or without logging) is the other.  "Bad MAC discard without logging" is not a separate action from "Bad MAC discard with logging".  "Bad MAC discard" is a single action with some level (debug/info/error) that may or may not result in a log record being generated.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, May 22, 2013 9:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] TLS1.2 vs TLS1.0

	

	

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 May 2013 23:30:58 +0200

> Just the opposite.  TLSv1.0 and TLSv1.1 are still perfectly fine for use,

I believe a statement like that should be qualified a bit: it is
_possible_ to implement TLSv1.0 and TLSv1.1 securely, but if you only
follow RFC 2246 and RFC 4346 you will run into issues.

Thus, for an external organisation wishing to reference a document
describing secure implementation and use of TLS, I would say that
referencing TLSv1.2 and requiring a AEAD mode is the only safe approach
today.

One alternative would be to reference TLSv1.0 and/or TLSv1.1 and also to
reference all published attacks (e.g., CBC and compression) which
usually contains a recommendation for implementers.

Another alternative is for this WG to take on revising the TLSv1.0 and
TLSv1.1 documents to recommend what is necessary in order to end up with
a secure TLSv1.0 and TLSv1.1 implementation.  Is there any interest in
this?

/Simon