Re: [TLS] TLS Digest, Vol 86, Issue 19

Gloria <gjserrao8@gmail.com> Fri, 23 September 2011 14:15 UTC

Return-Path: <gjserrao8@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6721F8CA9 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2011 07:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBPDdsIEc6ok for <tls@ietfa.amsl.com>; Fri, 23 Sep 2011 07:15:08 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1EC121F8C80 for <tls@ietf.org>; Fri, 23 Sep 2011 07:15:07 -0700 (PDT)
Received: by gwj15 with SMTP id 15so3458115gwj.31 for <tls@ietf.org>; Fri, 23 Sep 2011 07:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=qGVCbNf/yeTpx7yX5CUwg+iCvW1PR92C/6QDz3Et4iM=; b=kfge/v46FM3/5nu66ZFBvZsx2cSfKP+Rl1GC+qu2ezU08qdoNGczdthk+ubjPutinK 9YLSwjS/IhCz3eAvWBV27c0MOsNIr6IUSUe9jdo9VJ5vtnNt07LV5Ln62QHvlqMwrJN/ FJ+tjM/uZSaKFy7fTfn/M25qK0e1YPjENYo08=
Received: by 10.150.52.11 with SMTP id z11mr2230296ybz.304.1316787460941; Fri, 23 Sep 2011 07:17:40 -0700 (PDT)
Received: from localhost (54.sub-174-252-134.myvzw.com. [174.252.134.54]) by mx.google.com with ESMTPS id m4sm2686649ybc.5.2011.09.23.07.17.36 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 07:17:38 -0700 (PDT)
Date: Fri, 23 Sep 2011 10:17:47 -0400
Message-ID: <ih8ktvxhclx6l5r532gg5gjl.1316787467208@email.android.com>
From: Gloria <gjserrao8@gmail.com>
To: tls@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Subject: Re: [TLS] TLS Digest, Vol 86, Issue 19
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2011 14:15:09 -0000


Sent from my Verizon Wireless Phone

tls-request@ietf.org wrote:

>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
>	tls@ietf.org
>
>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
>	tls-request@ietf.org
>
>You can reach the person managing the list at
>	tls-owner@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of TLS digest..."
>
>
>Today's Topics:
>
>   1. Re:  interop for TLS clients proposing TLSv1.1
>      (Yngve N. Pettersen (Developer Opera Software ASA))
>   2. Re:  interop for TLS clients proposing TLSv1.1 (Martin Rex)
>   3. Re:  interop for TLS clients proposing TLSv1.1 (Martin Rex)
>   4. Re:  interop for TLS clients proposing TLSv1.1 (Geoffrey Keating)
>   5. Re:  interop for TLS clients proposing TLSv1.1 (Peter Gutmann)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 22 Sep 2011 01:19:38 +0200
>From: "Yngve N. Pettersen (Developer Opera Software ASA)"
>	<yngve@opera.com>;
>To: "Martin Rex" <mrex@sap.com>;
>Cc: tls@ietf.org
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <op.v16lq0saqrq7tp@acorna.oslo.osa>;
>Content-Type: text/plain; charset=iso-8859-15; format=flowed;
>	delsp=yes
>
>On Thu, 22 Sep 2011 00:30:48 +0200, Martin Rex <mrex@sap.com>; wrote:
>
>> Yngve N. Pettersen wrote:
>>>
>>> On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex <mrex@sap.com>; wrote:
>>>
>>> > Does anyone (SSL Labs, Opera, others) have any figures/stats about the
>>> > current "TLSv1.1 version (in)tolerance" for TLS servers on the public
>>> > internet?
>>>
>>> This week's test of 609726 servers gave these numbers:
>>>
>>>    * 1.145% of the probed servers were version intolerant for at least  
>>> one
>>>      of the current TLS versions (1.0, 1.1, 1.2)
>>>    * 1.742% were extension intolerant for the same versions
>>>    * 1.136% belonged in both groups
>>>
>>> This gives an estimated total of 1.751% that are either version and/or
>>> extension intolerant for the currently defined TLS versions.
>>
>> OK, I'll try to be more specific about the numbers that
>> *I* would be interest in (in case you could extract from your data):
>>
>> When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer),
>> how many servers abort immediately, depending on the value of the
>> client_version:
>>
>>     for client_version = { 0x03,0x00 }   (SSLv3)
>>     for client_version = { 0x03,0x01 }   (TLSv1.0)
>>     for client_version = { 0x03,0x02 }   (TLSv1.1)
>>     for client_version = { 0x03,0x03 }   (TLSv1.2)
>>
>> and how many continue the handshake but fail the finished macs?
>
>I am currently not registering data that detailed (although I do register  
>results for each tested client_version value tested, the results are not  
>that fine-grained), and IMO it does not really make that much a difference  
>(to the client) if the server just shut down the connection, or failed the  
>finished message; establishing the connection still failed.
>
>As mentioned earlier I do register servers that refuse to accept a SSL v3  
>record protocol for the Hello, but require a TLS 1.0 instead (the number  
>of servers that require that, and are included in the above version  
>intolerance count is 29, 0.005 percentage points)
>
>One case where we do (implictly) get a failure during the finished mac, is  
>for the 0.117% of servers that mirror any version back, even if they do  
>not support it.
>
>The number of servers that require the RSA client key exchange version  
>field to be the same as the negotiated version, not sent version, is about  
>4.6% (April 2011; data not reliable since then :( ): about 27% ignore that  
>version field.
>
>-- 
>Sincerely,
>Yngve N. Pettersen
>********************************************************************
>Senior Developer		     Email: yngve@opera.com
>Opera Software ASA                   http://www.opera.com/
>Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
>********************************************************************
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 22 Sep 2011 01:20:32 +0200 (MEST)
>From: Martin Rex <mrex@sap.com>;
>To: geoffk@geoffk.org (Geoffrey Keating)
>Cc: tls@ietf.org
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <201109212320.p8LNKWl5023077@fs4113.wdf.sap.corp>;
>Content-Type: text/plain; charset=ISO-8859-1
>
>Geoffrey Keating wrote:
>> 
>> 
>> > Does anyone (SSL Labs, Opera, others) have any figures/stats about the
>> > current "TLSv1.1 version (in)tolerance" for TLS servers on the public
>> > internet?
>> 
>> I find that about 1.4% of servers will refuse to connect using a TLS 1.2
>> hello but will connect using a TLS 1.0 hello.  Some of those might be
>> unhappy about something else in the TLS 1.2 hello (extensions, for
>> example).  The other 99% accept a TLS 1.2 hello, even though only a small
>> fraction (about 0.15%) actually supports TLS 1.1 or 1.2.
>> 
>> > The TCP RST in the above situation, as described in Stevens' Network
>> > Programming, Section 7.5, Socket Option SO_LINGER, only indicates the
>> > specific SO_LINGER setting that the server had used for his side
>> > of the connection / his socket (Fig. 7.10  close() l_onoff=1, l_linger=0)
>> > 
>> > The SO_LINGER setting for a socket is entirely at the discretion of each peer
>> > and closing the socket immediately after sending a fatal alert is exactly
>> > what the TLS spec suggests:
>> > 
>> >    http://tools.ietf.org/html/rfc2246#section-7.2.2
>> > 
>> >    7.2.2. Error alerts
>> > 
>> >    Error handling in the TLS Handshake protocol is very simple. When an
>> >    error is detected, the detecting party sends a message to the other
>> >    party. Upon transmission or receipt of an fatal alert message, both
>> >    parties immediately close the connection. 
>> > 
>> >           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!
>> 
>> RFC 793 says, in section 3.5, that a connection is closed by sending a
>> FIN.  A RST is not a close of the connection but an abort; as RFC 793
>> says, "Such a message indicates to the site B TCP that something is
>> wrong, and it is expected to abort the connection."
>
>Your on the wrong page, see RFC1122 Section 4.2.2.13.
>Sending RST on cluse, indicating loss of data (that includes future
>loss of data).
>
>When not lingering on close, the server closes and destroys the socket
>immediately, there will not be a graceful three way handshake and the
>server does not care whether the data is received by the recipient,
>not even whether the data is delivered by the network.
>
>
>> 
>> However, the question of how to close the connection is secondary,
>> because it should not have been closed in the first place; as the blog
>> entry says, "The server isn't supposed to behave this way---it's
>> instead expected to simply reply using the latest HTTPS protocol
>> version it supports".  You can't really expect software that's broken
>> in one way to work perfectly in all other ways...
> 
>
>You're missing the point.  The blog is describing a reconnect fallback
>implemented in WinINET, and writes that the fallback fails to work
>because the server behaves incorrectly.  This is wrong,  The server
>behaviour is perfectly fine, but the described reconnect fallback
>logic is flawed.
>
>
>-Martin
>
>
>------------------------------
>
>Message: 3
>Date: Thu, 22 Sep 2011 01:50:35 +0200 (MEST)
>From: Martin Rex <mrex@sap.com>;
>To: yngve@opera.com (Yngve N. Pettersen)
>Cc: tls@ietf.org
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <201109212350.p8LNoZUk024729@fs4113.wdf.sap.corp>;
>Content-Type: text/plain; charset=ISO-8859-1
>
>Yngve N. Pettersen wrote:
>> 
>> Martin Rex wrote:
>> > 
>> > When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer),
>> > how many servers abort immediately, depending on the value of the
>> > client_version:
>> >
>> >     for client_version = { 0x03,0x00 }   (SSLv3)
>> >     for client_version = { 0x03,0x01 }   (TLSv1.0)
>> >     for client_version = { 0x03,0x02 }   (TLSv1.1)
>> >     for client_version = { 0x03,0x03 }   (TLSv1.2)
>> >
>> > and how many continue the handshake but fail the finished macs?
>> 
>> I am currently not registering data that detailed (although I do register  
>> results for each tested client_version value tested, the results are not  
>> that fine-grained), and IMO it does not really make that much a difference  
>> (to the client) if the server just shut down the connection, or failed the  
>> finished message; establishing the connection still failed.
>
>Thank you very much for providing the information that have collected.
>It's not that I urgently need exactly that information.  I'm mainly
>trying to figure out what is the most interoperable set of "features" for
>a ClientHello for a TLS client that is _not_ capable of reconnect fallback.
>
>> 
>> The number of servers that require the RSA client key exchange version  
>> field to be the same as the negotiated version, not sent version, is about  
>> 4.6% (April 2011; data not reliable since then :( ): about 27% ignore that  
>> version field.
>
>Thank you very much for reminding me of this problem.  I had entirely
>forgotten about this, and that number (4.6%) is quite disappointing.
>
>Add to that the RSA client key exchange version bug that Microsoft
>has shipped with Windows 7 SChannel for the renegotiation handshake,
>where they check the premaster secret version against the proposed
>version of the initial handshake instead of the proposed version
>of the current handshake and you will get the bottom line that
>suggesting the use of TLS version 1.1 or 1.2 through
>ClientHello.client_version will result in a significant amount
>of interop problems.
>
>I really think we (the TLS WG) should provide a remedy to this awful
>situation for the TLS protocol version negotiation in the installed base.
>
>
>> 
>> As mentioned earlier I do register servers that refuse to accept a SSL v3  
>> record protocol for the Hello, but require a TLS 1.0 instead (the number  
>> of servers that require that, and are included in the above version  
>> intolerance count is 29, 0.005 percentage points)
>
>OK.  I personally don't see those as a problem because I consider
>SSLv3 and TLSv1.0 equivalent when used with any of the regular
>SSLv3 cipher suites plus rfc3268 AES.
> 
>> 
>> One case where we do (implictly) get a failure during the finished mac, is  
>> for the 0.117% of servers that mirror any version back, even if they do  
>> not support it.
>
>While being technically different, those will likely be covered by
>a fairly conservative strategy of exclusively using either
>
>   SSLRecord.protocol         = { 0x03,0x00 } 
>   ClientHello.client_version = { 0x03,0x01 }
>
>or
>
>   SSLRecord.protocol         = { 0x03,0x01 } 
>   ClientHello.client_version = { 0x03,0x01 }
>
>for a client without reconnect fallback.
>
>-Martin
>
>
>------------------------------
>
>Message: 4
>Date: 21 Sep 2011 17:09:42 -0700
>From: Geoffrey Keating <geoffk@geoffk.org>;
>To: mrex@sap.com
>Cc: tls@ietf.org
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <m239fpe8u1.fsf@localhost.localdomain>;
>Content-Type: text/plain; charset=us-ascii
>
>Martin Rex <mrex@sap.com>; writes:
>
>> Geoffrey Keating wrote:
>> > RFC 793 says, in section 3.5, that a connection is closed by sending a
>> > FIN.  A RST is not a close of the connection but an abort; as RFC 793
>> > says, "Such a message indicates to the site B TCP that something is
>> > wrong, and it is expected to abort the connection."
>> 
>> Your on the wrong page, see RFC1122 Section 4.2.2.13.
>> Sending RST on cluse, indicating loss of data (that includes future
>> loss of data).
>> 
>> When not lingering on close, the server closes and destroys the socket
>> immediately, there will not be a graceful three way handshake and the
>> server does not care whether the data is received by the recipient,
>> not even whether the data is delivered by the network.
>
>I think we're agreeing?  For the purposes of TLS, you definitely don't
>want to do an abort by sending a RST, because it doesn't guarantee
>that the alert gets delivered to the endpoint---even if it gets
>physically sent, and it's not dropped in transit, the other end may
>discard it before delivering it to the TLS layer (flushing its buffers
>on receipt of a RST).
>
>
>------------------------------
>
>Message: 5
>Date: Thu, 22 Sep 2011 22:25:44 +1200
>From: Peter Gutmann <pgut001@cs.auckland.ac.nz>;
>To: mrex@sap.com
>Cc: tls@ietf.org
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <E1R6gTQ-0000IT-MW@login01.fos.auckland.ac.nz>;
>
>Martin Rex <mrex@sap.com>; writes:
>
>>Likewise, if my analsis is correct and that Blog accurately describes
>>WinINETs behaviour, that WinINET behaviour should be fixed to allow MSIE
>>users on Win7 to enable TLSv1.1 with less risk of interop problems.
>
>I've been told this is an artefact of schannel/wininet layering, that there's
>no way for schannel to communicate the necessary info to wininet, so it
>responds with a RST.  There are other situations where it does this as well,
>not just protocol-version issues.  There's apparently no easy way to fix this
>without considerable re-architecting.
>
>Peter.
>
>
>------------------------------
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls
>
>
>End of TLS Digest, Vol 86, Issue 19
>***********************************