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

[Gloria <[e-mail]>]

Sent from my Verizon Wireless Phone

[e-mail] 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
>	[e-mail]
>
>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
>	[e-mail]
>
>You can reach the person managing the list at
>	[e-mail]
>
>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)"
>	<[e-mail]>
>To: "Martin Rex" <[e-mail]>
>Cc: [e-mail]
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <[e-mail]>
>Content-Type: text/plain; charset=iso-8859-15; format=flowed;
>	delsp=yes
>
>On Thu, 22 Sep 2011 00:30:48 +0200, Martin Rex <[e-mail]> wrote:
>
>> Yngve N. Pettersen wrote:
>>>
>>> On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex <[e-mail]> 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: [e-mail]
>Opera Software ASA                   http://www.opera.com/
>Phone:  [phone]              Fax:    [phone]
>********************************************************************
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 22 Sep 2011 01:20:32 +0200 (MEST)
>From: Martin Rex <[e-mail]>
>To: [e-mail] (Geoffrey Keating)
>Cc: [e-mail]
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <[e-mail]>
>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 <[e-mail]>
>To: [e-mail] (Yngve N. Pettersen)
>Cc: [e-mail]
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <[e-mail]>
>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 <[e-mail]>
>To: [e-mail]
>Cc: [e-mail]
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <[e-mail]>
>Content-Type: text/plain; charset=us-ascii
>
>Martin Rex <[e-mail]> 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 <[e-mail]>
>To: [e-mail]
>Cc: [e-mail]
>Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
>Message-ID: <[e-mail]>
>
>Martin Rex <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
>
>
>End of TLS Digest, Vol 86, Issue 19
>***********************************