gmane.ietf.tls

Re: TLS1.2 vs TLS1.0

Eric Rescorla — 2013-05-23T01:29:55


Unsurprisingly, I don't agree with this interpretation.

-Ekr
_______________________________________________
TLS mailing list
TLS< at >ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: TLS1.2 vs TLS1.0

Martin Rex — 2013-05-23T01:20:22


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

Re: TLS1.2 vs TLS1.0

Martin Rex — 2013-05-23T00:51:45

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

Re: TLS1.2 vs TLS1.0

Martin Rex — 2013-05-22T22:52:25

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/



... 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



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





Whether "timing" provides an attack surface depends on several factors.
Timing may enable a decry

Re: TLS1.2 vs TLS1.0

Geoffrey Keating — 2013-05-22T00:38:19


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.


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


Not that I know of.


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".

Re: TLS1.2 vs TLS1.0

Ulrich Herberg — 2013-05-22T00:13:25

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 Herber

Re: TLS1.2 vs TLS1.0

Ulrich Herberg — 2013-05-21T23:45:14

Hi Hanno,

thank you for the recommendations. Please see below:

On Tue, May 21, 2013 at 1:26 AM, Hanno Böck <hanno< at >hboeck.de> wrote:
[...]


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

Re: TLS1.2 vs TLS1.0

Eric Rescorla — 2013-05-21T22:42:27


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
_______________________________________________
TLS mailing list
TLS< at >ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: TLS1.2 vs TLS1.0

Xiaoyong Wu — 2013-05-21T17:16:20

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

Re: TLS1.2 vs TLS1.0

Ulrich Herberg — 2013-05-21T16:25:53

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

Ulrich

On Tue, May 21, 2013 at 7:37 AM, Martin Rex <mrex< at >sap.com> wrote:

Re: TLS1.2 vs TLS1.0

Martin Rex — 2013-05-21T14:37:10

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.




Now that

Re: TLS1.2 vs TLS1.0

Paterson, Kenny — 2013-05-21T14:01:11

Hi

On 21 May 2013, at 14:47, Martin Rex wrote:


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.


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

Re: TLS1.2 vs TLS1.0

Martin Rex — 2013-05-21T13:47:42

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.



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 sou

Re: TLS1.2 vs TLS1.0

David McGrew (mcgrew — 2013-05-21T11:05:33

+1 to what Hanno said.

David

On 5/21/13 4:26 AM, "Hanno Böck" <hanno< at >hboeck.de> wrote:

Re: TLS1.2 vs TLS1.0

Hanno Böck — 2013-05-21T08:26:47

On Mon, 20 May 2013 13:47:08 -0700
Ulrich Herberg <ulrich< at >herberg.name> wrote:


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,

Re: TLS1.2 vs TLS1.0

Nikos Mavrogiannopoulos — 2013-05-21T08:12:21

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.


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).


Many also do.


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

regards,
Nikos

Re: TLS1.2 vs TLS1.0

Robert Cragie — 2013-05-21T07:05:20

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

Robert

On 20/05/2013 22:43, Paul Duffy wrote:


_______________________________________________
TLS mailing list
TLS< at >ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: TLS1.2 vs TLS1.0

Paul Duffy — 2013-05-20T21:43:44

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:

TLS1.2 vs TLS1.0

Ulrich Herberg — 2013-05-20T20:47:08

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 su

Re: comments on draft-balfanz-tls-channelid

Adam Langley — 2013-05-14T20:57:23

Thanks! I can answer a few of the techincal questions. I'll leave your
comments on the wording and such to Dirk.



It would mean that clients send, in the clear, a unique identifier for
each eTLD+1. This would allow TLS connections to be deanonymised etc.


They are certainly related. Something like ChannelIDs could be
implemented at the application layer by signing channel binding
values. I think channel bindings were designed to provide exactly
this, but to the application.


I think it's primarily a privacy concern.


The session resumption information is sufficient to authenticate with
a given client certificate. That is, if the client certificate is in a
hardware token and signs a TLS handshake, then by stealing the session
resumption information (from either end of the connection), an
attacker steals something equivalent to the client-cert private key in
some sense.


Yes.


Yes.


It's certainly expected that the client would use the same public key
(i.e. (x, y) pair), yes.


Yes.


No, the Channel I

Re: AD review of draft-ietf-tls-oob-pubkey

Sean Turner — 2013-05-14T19:20:44

Joe you read my mind.  I'm also okay without the MUST.


Not thrilled with this answer but I could live with it.

How about adding a new section that groups these two issues together and 
call it "What specifications that use this document must specify" or 
something like that.

spt