Subject: Re: [TLS] TLS Digest

From: SPRONGL Christoph <[email-masked]>
Date: Tue, 24 Nov 2009 13:31:40 +0100

How is the roadmap of the proposal? - When will the time for the updates come?

ch

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Dienstag, 24. November 2009 12:22
An: [email-masked]
Betreff: TLS Digest, Vol 64, Issue 130

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/tls

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send TLS mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."

Today's Topics:

   1. Re:  Proposal for hybrid solution using most of the ideas
      (Nelson B Bolyard)
   2. Re:  Proposal for hybrid solution using most of the ideas
      (Nicolas Williams)
   3. Re:  draft-mrex-tls-secure-renegotiation-00.txt (Martin Rex)
   4. Re:  Proposal for hybrid solution using most of the ideas
      (Nelson B Bolyard)
   5. Re:  Proposal for hybrid solution using most of the ideas
      (Marsh Ray)
   6. Re:  draft-mrex-tls-secure-renegotiation-00.txt submitted
      (Yoav Nir)
   7. Re:  Proposal for hybrid solution using most of the ideas
      (Yoav Nir)
   8. Re:  draft-mrex-tls-secure-renegotiation-00.txt submitted
      (Simon Josefsson)

----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Nov 2009 14:58:02 -0800
From: Nelson B Bolyard <[email-masked]>
Subject: Re: [TLS] Proposal for hybrid solution using most of the
        ideas
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=UTF-8

On 2009-11-23 14:11 PST, Ben Laurie wrote:
> On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex <[email-masked]> wrote:
>> It is the golden rule of the IETF
>> "be liberal in what you accept, be conservative in what you send out"
>
> That has proved to be a less-than-great idea, particularly in
> protocols where you care about security, which is to say, all of them.

Precisely.

------------------------------

Message: 2
Date: Mon, 23 Nov 2009 17:16:47 -0600
From: Nicolas Williams <[email-masked]>
Subject: Re: [TLS] Proposal for hybrid solution using most of the
        ideas
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

On Mon, Nov 23, 2009 at 02:11:56PM -0800, Ben Laurie wrote:
> On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex <[email-masked]> wrote:
> > It is the golden rule of the IETF
> > "be liberal in what you accept, be conservative in what you send out"
>
> That has proved to be a less-than-great idea, particularly in
> protocols where you care about security, which is to say, all of them.

Sure, but consider this: a conservative design should fail safe.  The RI
proposal, as Michael D'Errico points out, allows for implementation
failures that fail unsafe.

Any alternative that has the two peers add the channel binding data for
the outer/old connection to the Finished message verify_data computation
without _sending_ the data as well will fail safe.

IMO there are better solutions, but the RI proposal is ready for
deployment at a moment's notice, and it is correct even if implementors
can make this one annoying mistake and not notice.  That is a huge plus
for the RI proposal.

Nico
--

------------------------------

Message: 3
Date: Tue, 24 Nov 2009 02:14:53 +0100 (MET)
From: Martin Rex <[email-masked]>
Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

>
> http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt

One of the first feedback I received indicates that the amount of
details in the document might make it appear much more complicated as it is.

The idea of my proposal is to keep the changes to an absolute
minimum (but offer secure renegotiation to all usage scenarios
in the installed base).

Solution brief:

  1.) memorize verify_data from Client.Finished and Server.Finished
      in ConnectionState of current session

  2.) on renegotiation handshakes, add memorized verify_data into
      handshake message hash to establish cryptographic binding

  3.) C->S signaling with special cipher suite ID

  4.) S->C signaling through highest bit in ServerHello.server_version

additional explanation:

1.) is something that TLS extension RI needs as well

2.) is TLS extension RI on a diet and in failSAFE mode:
      - no fancy extension wrapping,
      - no re-send of the previous finished messages over the network
      - identical cryptographic properties, as described here:
    http://www.ietf.org/mail-archive/web/tls/current/msg04194.html

TLS extension RI signals by presence of the extension,
my proposal signals extension-less through existing protocol
elements  3) is compatible with SSLv3 and SSLv2 ClientHello,
4) is compatible with SSLv3 ServerHello

3.) self-explaining, I hope

4.) I'm not changing the protocol version numbers anywhere in the
    protocol, just hitch-hiking an unused bit in
    ServerHello.server_version while traveling the network

    that hitch-hiking bit must be removed for all protocol-version
    related processing of server_version and not appear anywhere else,
    neither on the network and not in the code,
    beside the code that assembles the ServerHello PDU on the server
    and the code that parses the ServerHello PDU on the client.

    It will only be returned to clients sending (3).

-Martin

------------------------------

Message: 4
Date: Mon, 23 Nov 2009 21:11:02 -0800
From: Nelson B Bolyard <[email-masked]>
Subject: Re: [TLS] Proposal for hybrid solution using most of the
        ideas
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=UTF-8

On 2009-11-23 12:43 PST, Martin Rex wrote:
> Nelson B Bolyard wrote:
>>                             I disagree with changing the definition of
>> the finished messages without changing the protocol version number.
>> The IMPORTANT thing that RI accomplishes is that it gets the needed
>> information included in the Finished message computations WITHOUT changing
>> the definition of the Finished message computations.  That is precisely
>> its strength!  That is precisely why I support it.

It does not change the finished message, or the computation of the handshake
hashes.  All remain 100% computable from the inputs to the
present handshake.

> Great!  So you will not have a problem with my proposal either,
> because mine does not change the finished message computation
> either.
>
> http://www.ietf.org/mail-archive/web/tls/current/msg04194.html

Your change makes the handshake hash (and hence the finished) no longer
computable purely from the input to the current handshake.

> From a cryptograpic standpoint, adding the verify_data into
> the handshake message hashes without sending them over
> the network is equivalent to adding them to the handshake
> messages itself, sending them over the wire and having
> to compare the values explicitly.
>
> Just that directly hashing them is less work

It's a bigger code change, which is more to get wrong.
Where have I heard that argument used before?

------------------------------

Message: 5
Date: Tue, 24 Nov 2009 01:56:10 -0600
From: Marsh Ray <[email-masked]>
Subject: Re: [TLS] Proposal for hybrid solution using most of the
        ideas
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Ben Laurie wrote:
> On Sun, Nov 22, 2009 at 7:06 PM, Martin Rex <[email-masked]> wrote:
>> It is the golden rule of the IETF
>> "be liberal in what you accept, be conservative in what you send out"
>
> That has proved to be a less-than-great idea, particularly in
> protocols where you care about security, which is to say, all of them.

Another way to think about it: any time a receiver is being liberal in
what it accepts the protocol is depending on undefined behavior.

- Marsh

------------------------------

Message: 6
Date: Tue, 24 Nov 2009 10:42:12 +0200
From: Yoav Nir <[email-masked]>
Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt
        submitted
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Martin.

I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header.

Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols.

On Nov 23, 2009, at 5:57 PM, Martin Rex wrote:

> I have just submitted my proposal (I-D) to the IETF datatracker.
>
> http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt
>
>
> -Martin

------------------------------

Message: 7
Date: Tue, 24 Nov 2009 11:08:00 +0200
From: Yoav Nir <[email-masked]>
Subject: Re: [TLS] Proposal for hybrid solution using most of the
        ideas
To: David-Sarah Hopwood <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

On Nov 23, 2009, at 10:06 PM, David-Sarah Hopwood wrote:

> Yoav Nir wrote:
>> On Nov 23, 2009, at 5:06 AM, Nelson B Bolyard wrote:
>>
>>> On 2009-11-22 18:30 PST, Michael D'Errico wrote:
>>>> If you take an elitist position like the one you seem to be advocating,
>>>> you run the risk that your "pure" standard-compliant fix will be ignored
>>>> and people will come up with their own solutions.  You will quickly
>>>> become irrelevant.
>>>
>>> The purveyors of all those old non-compliant products are desperately
>>> afraid that the browsers will unify and decide as a group to stop supporting
>>> fall-back for extension intolerant servers.  Then those old
>>> servers would quickly become irrelevant.
>>
>> Actually, patching servers is a lot easier than patching browsers. It's fairly easy for a server administrator to replace the necessary library (OpenSSL 0.9.8m?) with one that does TLS 1.3 and then we don't need any extensions.
>>
>> But these same servers need to support all the clients out there. That includes the latest Firefox, but also the ever-prevalent IE6 on XP (with and without patches and service packs), as well as an old iMac running Mac OS 8.6 with a Mozilla browser, and various phones.
>>
>> So if the browsers unify, that's great. Maybe the browsers will standardize on TLS 1.3 and we can drop support for all older versions the moment we decide that it's time to drop support for all pre-2010 browsers.  I think 2022 should do it.
>>
>> In the meantime, we can't ignore that IE6 running on no-SP Windows XP.
>
> Your argument is self-defeating: if browsers are only upgraded slowly
> (by some subset of users), then that is an extremely good reason not to
> rely on browsers to be upgraded in order to prevent the attack. The only
> possible way to do that is for patched servers to reject renegotiations
> from unpatched browsers -- because such renegotiations cannot be
> distinguished from an instance of the attack.
>
> This will not break initial connections from unpatched browsers. It will
> require that servers avoid relying on renegotiation, but they can easily
> do so in a way that is compatible with IE6 or other unpatched browsers
> (for the most common use case of renegotiation -- prompting for a client
> cert for only some of the resources on a site -- it is sufficient to serve
> those resources on a different port).

A different port is hard, but the usual way is to have a "login_with_mutual_authentication.html" page, that is the only one where the renegotiation is performed. That page plants a session cookie in the browser, if such a cookie does not yet exist, and performs no other action. You also need to reject client-initiated renegotiation.

If you do that, the only way for the attacker to force a renegotiation, is to GET login_with_mutual_authentication.html, before the user logged in. This will plant a cookie in the browser of the legitimate client, but that cookie cannot be used for the attack, because the client's request has already been created without the cookie.

That's a way to support old browsers without being vulnerable. It only requires a mild change to SSL (no client-initiated reneg) and a mild hardening of the application.

------------------------------

Message: 8
Date: Tue, 24 Nov 2009 12:21:44 +0100
From: Simon Josefsson <[email-masked]>
Subject: Re: [TLS] draft-mrex-tls-secure-renegotiation-00.txt
        submitted
To: Yoav Nir <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Yoav Nir <[email-masked]> writes:

> Hi Martin.
>
> I see that you use the protocol field for the S->C signaling, but at least it's on the ServerHello rather than the handshake record header.
>
> Still, I'm worried about firewall/IPS/IDS devices that deep-inspect protocols. A server answering with the wrong SSL version may just be "weird" enough for the middlebox to drop the connection. I'm not at that side of Check Point, but I know that much of the protection code is not targeted at a particular attack, but just performs a sanity check on the protocols.

Presumably RI has the same concern: a deep-packet inspector may check
for "unknown" extensions (similar to checking for "unknown" TLS
versions) and reject the connection.

I don't think this is a good argument to decide between the two
proposals.  IDSs will simply need to be upgraded to support one (or
both) of the new proposals, and fortunately that is already required for
other reasons, so it seems like a small concern to me.

/Simon

> On Nov 23, 2009, at 5:57 PM, Martin Rex wrote:
>
>> I have just submitted my proposal (I-D) to the IETF datatracker.
>>
>> http://www.ietf.org/id/draft-mrex-tls-secure-renegotiation-00.txt
>>
>>
>> -Martin

------------------------------

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

End of TLS Digest, Vol 64, Issue 130
************************************