Subject: [TLS] Server can send an alert

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 16:35:16 -0800

This proposed solution is a summary of many ideas from the
list, but with a twist: the server can send an alert message
to the client (I realize it's not included in the handshake
hash but that doesn't matter -- see below).

We all seem to agree that the flaw is due to a problem with
the Finished calculation.  If only it had included some info
from previous handshakes, this problem would not exist.  So
to fix that, we can add a "virtual" handshake message such
as this:

     struct {
        opaque previous_client_verify_data<0..255>;
        opaque previous_server_verify_data<0..255>;
     } PreviousVerifyData;

Where exactly this gets inserted into the stream of handshake
messages doesn't matter to me.  The important feature is that
it will always include at least two bytes, so it is not
compatible with current Finished calculations.

Then all that is needed is a way for a client and server to
signal their support.  Using a magic cipher suite is the
most interoperable thing the client can send since servers
already have code to process a variable-length list.  We
could add a requirement that this magic cipher suite MUST be
the first in the list to make the server code simpler.

Upon receiving the magic cipher suite, the server would send
a Warning alert (with a new number) to signal to the client
that it will use the new Finished calculation.  This MUST be
sent before ServerHello.

When the client receives the alert, it switches to the new
Finished calculation as well.

A MITM can not mess with this successfully.

If it removes the magic cipher suite, the old Finished
calculation will be used by both the client and server, but
since the server's handshake messages are not the same as
the client's, the handshake will fail.

If it lets the magic cipher suite get to the server, but
blocks the alert message, then the server will be using the
new Finished calculation while the client uses the old, so
that handshake will fail too.

I'm pretty sure that both sides can detect this tampering,
if they put in the effort, but I haven't thought through it
sufficiently.

Since the only bits on the wire change is an additional cipher
suite, servers will not have a problem with it.  Failure to
handshake should not cause fall back behavior (i.e. retrying
without the cipher suite).

The only thing I don't like is that by blocking the alert
message, a MITM can cause denial of service to a "strict"
client.  But they can deny service in many other ways, so this
is probably not important.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2009 07:10:09 +0200

At Mon, 16 Nov 2009 16:35:16 -0800,
> hash but that doesn't matter -- see below).

This seems like a fairly unattractive idea to me. It's not what
alerts were intended for and IIRC many implementations don't
currently handle warning level extensions (aside from
close_notify) very well. I.e., they treat them as an error.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Nov 2009 12:19:17 -0600

> close_notify) very well. I.e., they treat them as an error.

Or crash.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2009 18:23:58 +0000

At Tue, 17 Nov 2009 12:19:17 -0600,
> > close_notify) very well. I.e., they treat them as an error.

ISTM that an SSL/TLS implementation which crashes on any network
input (valid or otherwise) has some pretty serious problems
beyond our capacity to deal with.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 10:30:51 -0800

A better alternative has been proposed which I now support, but:

The alert would only be sent in response to the magic cipher suite
so the client would be expecting it.  If a client doesn't even have
alerts working right, how can you expect them to get *extensions*
right?

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 17 Nov 2009 21:31:09 +0000

> close_notify) very well. I.e., they treat them as an error.

Agreed. In general, those arguing against the use of extensions do
not seem to be considering that other signalling mechanisms can
potentially have interoperability problems at least as serious as
extensions, and will have been less well-tested than extensions.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 17 Nov 2009 21:50:07 +0000

> extensions, and will have been less well-tested than extensions.

Well to add a data point for OpenSSL...

TLS extensions were disabled by default in all released versions of OpenSSL
until 0.9.8j released on 07 Jan 2009. A (relatively small) number of issues were
reported relating to SSLv3 servers not handling extensions. It is hard to gauge
how many are affected because people will sometimes just read and adopt the
"solution" (disable extensions) and consider the job done.

By contrast I've never (in over 10+ years) come across a server that needed a
ciphersuite advertised in client Hello removed that it didn't actually
negotiate. Historically all sorts of unusual ciphersuites had been advertised in
SSLv3 (Fortezza and custom FIPS140-2 ones spring to mind).

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 02:28:06 +0100 (MET)

> extensions, and will have been less well-tested than extensions.

I privately told Michael that personally I'm against the idea of
using alerts, because these are often processed in completely
different code paths of the implementations, and some of
the existing implementations seems to have significant difficulties
dealing with SSL alerts.  That includes delivering Alerts to
the network or continuing after warning-level alerts (with very
few exemptions, like the no_certificate alert).

Microsoft SSL/TLS implementation seems to be a little stingy
when it comes to sending alerts.  ;)

The most appropriate location for signaling security parameters
from server to client is ServerHello.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 19:26:52 -0800

> from server to client is ServerHello.

After Martin suggested using the server version to signal the
server's support, I could see that it was far simpler than an
alert message, so I *changed my mind* and went with that in the
code I implemented this morning.

That is what engineers do.  They don't run with ideas simply
because they came up with them when there have been serious
problems pointed out.  Remember there is an E in IETF!  Not a
P (political), but an E.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Nov 2009 21:30:30 -0600

> code I implemented this morning.

Couldn't all the signaling could be solved with the version number fields?

Problem is, that's the one field that every client, server, and
inspecting firewall is looking at most closely. How will they react?

My intuition/experience suggests that touching those fields will break
lots of stuff.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 19:59:22 -0800

> Couldn't all the signaling could be solved with the version number fields?

I don't think so.  An unpatched server won't know what the new version
numbers mean if a client were to send them.  It would think the client
supports some version beyond TLS 1.2.  If the client is really a TLS 1.0
client + patch, and the server selects TLS 1.1 (its max version), then
you have an interoperability problem.

> My intuition/experience suggests that touching those fields will break

Well the only clients and servers that will ever see/use them are those
that are patched, so they are not a problem.  If there is a serious
problem with firewalls or other monitoring software, we can find a
different signal.  But on the other hand, firewalls and monitoring
software will want to be updated to look for patched SSL/TLS clients
and servers.  Using the version the way Martin suggested is easy to
check -- you just test a single bit in the server hello at a fixed
offset.

Consider monitoring software that needs to check for the RI extension
in the ServerHello extensions; there is currently no mandate for the
location of RI within the list, so the list must be parsed.  Okay, so
you can say it MUST be first, but that is yet another band-aid on a
bad solution.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 05:15:53 +0100 (MET)

> My intuition/experience suggests that touching those fields will break

I do hope that the firewalls and IDS systems out there are not going
to kill my prefered approach to use the ServerHello.server_version
field for signaling back from Server to Client.

I would prefer to re-purpose the bits from the top.
That signal is supposed to appear only in ServerHello.server_version
and nowhere else in protocol version fields,
in particular _not_ in the record layer.

The PDU data visualization in network sniffers like Wireshark
will likely need to learn the new number, but that should not
be an unsurmountable problem.

If we're considering making the secure renegotiation a requirement
for the next TLS protocol rev. (prohibiting the insecure renegotiation
when TLSv1.3 is negotiated), then it is much better when the
protocol version related code is fairly colocated.  The 
server-side code that builds ServerHello.server_version into
the PDU and the client-side code that parses the
ServerHello.server_version from the PDU seems fairly natural to me.

-Martin

---

From: <[email-masked]>
Date: Tue, 17 Nov 2009 23:40:51 -0500

There have been several posts which have discussed the possibility of re-using 
existing fields, rather than use the TLS extension mechanism. Using a field 
for anything but its intended purpose is fraught with danger. In particular, 
there has been discussion of re-purposing of bits of the TLS Protocol Version.

Our server code uses the TLS Protocol Version as a numeric value to negotiate 
the TLS version. If a client offers TLS 1.0 (3,1) and the server can do TLS 
1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS 1.2 
(3.3), and then chooses TLS 1.0 (3,1).

If the decision was to signal via the top bit of the protocol version, then an 
updated client might offer TLS 1.0 patched (0x83, 1) and a not updated server 
can do TLS 1.2 (3,3), the server determines that TLS 1.0patched (0x83,1) is 
greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)!

------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, 
AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 05:48:18 +0100 (MET)

I'm sorry for the confusion of the various discussions going on.

My idea is to use a bit in the server_version field of the ServerHello PDU
to transfer a signal from Server to Client only after the client has
indicated to understand this signal.

This signal bit is _NOT_ supposed to be used for ClientHello.client_version
_NOT_ for record layer version tagging and neither for the version
indicate in the TLS session state (because it might confuse existing code),
it is purely for transfer over the network.

-Martin

[email-masked] wrote:
> ------=_NextPart_000_102C_01CA685D.1FCAC4B0
> Content-Type: application/x-pkcs7-signature;
> 	name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> 	filename="smime.p7s"
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWmzCCAucw
> ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l
> dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz
> IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy
> dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa
> Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx
> FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj
> eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v
> MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
> gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ
> j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK
> mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ
> M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1
> s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV
> 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV
> BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs
> BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw
> MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV
> BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y
> ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD
> gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID
> 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i
> 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX
> i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh
> oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j
> ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED
> MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN
> QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO
> Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd
> oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD
> ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT
> LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho
> dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t
> MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5
> IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh
> a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
> tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3
> Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/
> eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw
> bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv
> bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV
> HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG
> 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys
> 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU
> vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w
> DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL
> Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU
> BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz
> MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy
> dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk
> MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB
> jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5
> /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW
> yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG
> A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1
> cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB
> Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v
> Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf
> BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y
> 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13
> qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt
> TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggR+MIID56ADAgECAhEAsSe9
> yNTH2rYKRiN7F8KhkTANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu
> Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg
> Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT
> MB4XDTA5MDcyMTA1MTYxM1oXDTExMDcyMjA1MTYxM1owgekxEzARBgoJkiaJk/IsZAEZFgNjb20x
> EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjEMMAoGA1UECxMD
> UlNBMRUwEwYDVQQLEwxBc2lhL1BhY2lmaWMxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQF
> EwYwNjQ4MTQxFzAVBgoJkiaJk/IsZAEBEwdyb2JpbnAyMRcwFQYDVQQDEw5QZXRlciBSb2JpbnNv
> bjElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNvbTCBnzANBgkqhkiG9w0BAQEF
> AAOBjQAwgYkCgYEA2CcjIV2QNoJP4YbPejhZX2MSu53/EooTnrkf7M4gsl1DobXkk3CO6kU9bN6O
> wwL/o87dQ4y2FHjwkV4WeoodhvZa08q5uX4vZCtB2Hn0OUrbPzyKl7wXSq+yezKCQJBrVCTwWjKK
> A6Gqc1VhkqWSBCpUaQ39TsVDxNYCGIn433cCAwEAAaOCAX8wggF7MIGSBgNVHSAEgYowgYcwgYQG
> CSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5o
> dG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNlY3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9y
> YXRlZCBieSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUF
> BwMEMCEGA1UdEQQaMBiBFnBldGVyLnJvYmluc29uQHJzYS5jb20wDgYDVR0PAQH/BAQDAgeAMEYG
> A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBl
> cnNvbmFsQ0EuY3JsMB8GA1UdIwQYMBaAFMaT7sal/uNVjs+KIx/umN4h8p+nMB0GA1UdDgQWBBQm
> 7p962rS9dUpGeQZt+Vi1su6tQTANBgkqhkiG9w0BAQUFAAOBgQCghPP5wxcDJuACPYJ/U1sjhyE4
> gxpGKZNPnnDcjfHo+Cq87cWawpV5Rzpg8KVZc0EoG6BabGNyk+WgZMjCzADpg+appN4cX+DML0ir
> 3cBcX8pQTuKw1VRlUjidjkTIl/Z2hrcvgh2lJG+PFV2ogWICzwOj4/zKG4khs9VO5NNPezCCBI4w
> ggP3oAMCAQICEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFS
> U0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xh
> c3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0
> czELMAkGA1UEBhMCVVMwHhcNMDkwNzIxMDUxNjE4WhcNMTEwNzIyMDUxMzM2WjCB7TETMBEGCgmS
> JomT8ixkARkWA2NvbTETMBEGCgmSJomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0
> aW9uMQwwCgYDVQQLEwNSU0ExFTATBgNVBAsTDEFzaWEvUGFjaWZpYzEUMBIGA1UECxMLRW5naW5l
> ZXJpbmcxDzANBgNVBAUTBjA2NDgxNDEXMBUGCgmSJomT8ixkAQETB3JvYmlucDIxGzAZBgNVBAMT
> ElBldGVyIFJvYmluc29uLUVuYzElMCMGCSqGSIb3DQEJARYWcGV0ZXIucm9iaW5zb25AcnNhLmNv
> bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqeM4888BmvaveugOJqTYWGNm3cTP6qJe444S
> 7AJaXDnKZlt1cJByB+B83hdGGe2FyRQGGef0DNZhQIfaa41dzZbDWuogZ3mKxyuOhciZSoRoCIM0
> jlPh5vqhDmXBPFQ/EedNPRk+tl+mKVz2fHbsI01bWtueV05BvJu330cj0WUCAwEAAaOCAYswggGH
> MDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDCB
> kgYDVR0gBIGKMIGHMIGEBgkqhkiG9w0FBwUwdzAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNl
> Y3VyaXR5LmNvbS9DUFMuaHRtbDBFBggrBgEFBQcCAjA5MBgWEVJTQSBTZWN1cml0eSBJbmMuMAMC
> AQEaHUNQUyBJbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMCEGA1UdEQQaMBiBFnBldGVyLnJvYmlu
> c29uQHJzYS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206
> ODAvUlNBQ2xhc3MyUGVyc29uYWxDQS5jcmwwHwYDVR0jBBgwFoAUxpPuxqX+41WOz4ojH+6Y3iHy
> n6cwHQYDVR0OBBYEFGg/pAQlQSo2dvZeyryhS2toL395MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG
> 9w0BAQUFAAOBgQCY/nGMkd29x8wULeVsTP+emR/XVn+LqcfwzgwpUSKP1FX1WedrHwlNKFaVDjQX
> FaNETkV4XzMugf4iafsgZUp5DmzIOBB5H5MI1k+CprZ0tjet7gcN0sdCt0fggfw44GZ37rwxzwyt
> XZrbEePtb8wFYVEobKBD/ZqvghavL93K3DGCA4EwggN9AgEBMIGiMIGMMRowGAYDVQQKExFSU0Eg
> U2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3Mg
> MiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEL
> MAkGA1UEBhMCVVMCEQCxJ73I1MfatgpGI3sXwqGRMAkGBSsOAwIaBQCgggI0MBgGCSqGSIb3DQEJ
> AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExODA0NDA1MFowIwYJKoZIhvcNAQkE
> MRYEFBSxQZqx25aScoyemzyU00DIq3udMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI
> KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO
> AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1
> cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl
> cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD
> VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD
> VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS
> U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj
> aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA
> TA4a793LczoeOI1ZdI5seyjHdi6FGOMKAd2eGL/EC4HdI4sb5avDdoTzykXOZ32qFfJ/8qtI+adg
> eY9U9g7Zx2m01edfxDomoEzTlMr31QJ1ZJexgdttEI6qu/kak0JmLIDpx1bKOsw7PPAQoOg+NIdT
> yEDMpDTMKQJhlapDAhIAAAAAAAA=
> 
> ------=_NextPart_000_102C_01CA685D.1FCAC4B0--
> 
> --===============2057096671==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> --===============2057096671==--
>

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Nov 2009 21:20:52 -0800

> greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)!

There is a misunderstanding.  A client would offer exactly the same version
numbers it does today.  Where the version number would differ is in the
ServerHello.version returned to the client ONLY IF the client sent the
"magic" cipher suite indicating it is expecting it.

A single bit would be set to indicate that the server is also patched.
Martin wants to use the upper bit of the major version number, but I think
using the upper bit of the minor version number might be better.  Using the
minor version would contain this to the 0x03 number space, so the next TLS
version can be 4.0 (0x0400), which will be larger than any of these pseudo
versions.

Further, the version used in the record layer would not change either.

This combination of a magic cipher suite and a bit flip in the server version
is extremely compatible with all protocol versions including SSLv3, whereas
adding extensions to SSLv3 to do RI (even if only that one) could be a
hardship for many codebases.  In fact this is even compatible with the
SSLv2 client hello!  (Though I'm sure many of you would consider that a
flaw....)

Mike

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Nov 2009 10:00:52 +0200

I'm very much against that.

The protocol version is something everyone looks at: clients, servers and middleboxes. 

OTOH the server_random field is treated as random. Yes, even the timestamp part.

I really believe that's the place for the server to signal.

As for the client signal, the fake ciphersuite is clean and not-elegant-but-ok.  However, for no reason other than aesthetics, the client signal should be similar to that of the server. And I'd use two magic values:
 - SUPPORT - (client or server) will use new calculation of Finished message
 - SAFE - (server only) Renegotiation is disabled. This allows a quicker fix. Not sure if this is really needed, though.

Then you just add the old verify_data to the Finished message, and there's no need for extensions.

---

From: "Robert Dugal" <[email-masked]>
Date: Wed, 18 Nov 2009 06:18:47 -0500

Me too. I am against doing anything that involves modifying the protocol version. 

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
[email-masked]
direct        905.501.3848
fax             905.507.4230
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, November 18, 2009 3:01 AM
To: [email-masked]
Cc: [email-masked] list
Subject: Re: [TLS] TLS Protocol Version

On Nov 18, 2009, at 6:48 AM, Martin Rex wrote:

> My idea is to use a bit in the server_version field of the ServerHello 
> PDU to transfer a signal from Server to Client only after the client 
> has indicated to understand this signal.
> 
> This signal bit is _NOT_ supposed to be used for 
> ClientHello.client_version _NOT_ for record layer version tagging and 
> neither for the version indicate in the TLS session state (because it 
> might confuse existing code), it is purely for transfer over the network.
> 
> -Martin
> 
>> There have been several posts which have discussed the possibility of 
>> re-using existing fields, rather than use the TLS extension 
>> mechanism. Using a field for anything but its intended purpose is 
>> fraught with danger. In particular, there has been discussion of re-purposing of bits of the TLS Protocol Version.
>> 
>> Our server code uses the TLS Protocol Version as a numeric value to 
>> negotiate the TLS version. If a client offers TLS 1.0 (3,1) and the 
>> server can do TLS
>> 1.2 (3,3), the server determines that TLS 1.0 (3,1) is less than TLS 
>> 1.2 (3.3), and then chooses TLS 1.0 (3,1).
>> 
>> If the decision was to signal via the top bit of the protocol 
>> version, then an updated client might offer TLS 1.0 patched (0x83, 1) 
>> and a not updated server can do TLS 1.2 (3,3), the server determines 
>> that TLS 1.0patched (0x83,1) is greater than TLS 1.2 (3,3), and then chooses TLS 1.2 (3,3)!
>> 
>> 
>> Peter Robinson - [email-masked] Engineering Manager RSA, The 
>> Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront 
>> Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 15:23:49 +0100 (MET)

If you are referring to the SSLv2 backwards-compatibility option,
that seems to be actually still used in Firefox 3.5 in the automatic
reconnect fallback should the server choke on TLS extensions.

And yes, *I* think it is a feature to even support this case,
because we're suggesting to quickly fix an urgent security problem
and _NOW_ is not the time to unnecessarily killing existing usage
scenarios, no matter how outdated they might look.

Requiring them to change that before shipping the patch would
be an unecessary burden, unnecessary risk and it could delay the
shipment of the patch.

If we want vendors and suppliers to ship this fix fast, then
we ought to try hard to _not_ break things, in particular,
not break things unnecessarily.

If, on the other hand, the TLS WG prefers the attitude:

"we know that using TLS extensions for the fix will break a number
 of existing usage scenarios, but we think these usage scenarios
 ought to be abandoned anyway, so we simply don't care."

then this will significantly slow down the deployment of patches,
since everyone will want to carefully test the existing usage
scenarios before risking to deploy the patch.

Improving interoperability with and tolerance for TLS extensions
could have been a working group item three years ago, when
the issue was brought to the attention of the TLS WG here
http://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00

when there was no time constraint on making TLS extensions usable
on he Internet.

-Martin

---

From: <[email-masked]>
Date: Wed, 18 Nov 2009 15:57:06 +0100

Hmm... not all clients today support renegotiation, and IMHO the fix
should be especially simple to deploy for those clients.  Those
clients could just include a magic cipher suite number in all client
hellos, meaning "this is not a renegotiation". This would be extremely
simple to implement, unlikely to break anything (old servers will
ignore it), and could be shipped as soon as we pick the cipher suite
number.

Obviously, when the client does want to do secure renegotiation, we
probably need two-way signalling, and we need to include the
verify_data (or both) from the previous handshake somewhere (not
necessarily on-the-wire) when doing renegotiation.

Would it make sense to agree on the behavior for clients that never do
renegotiation (1st paragraph above) before we know all the details for
doing secure renegotiation (2nd paragraph above)?

Best regards,
Pasi
(not wearing any hats)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Martin Rex
> Sent: 18 November, 2009 16:24
> To: Michael D'Errico
> Cc: [email-masked]

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 08:24:42 -0800

I like this idea -- it would be very easy to incorporate.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 17:47:56 +0100 (MET)

> doing secure renegotiation (2nd paragraph above)?

Sounds fine to me.

It doesn't interfere with the other work-in-progress in the TLS WG.
There may be an interference with patch production for vendors/suppliers
if they might need to ship two updates in a very short time instead
of just one.

I would prefer a positive description for that meaning,
maybe "this is an initial handshake".

There seems to be a ciphersuite range that only needs an
Expert Review and no IANA action, so getting a number assigned
there might be faster (require less formalities).

We would later need an additional ciphersuite ID for signaling
"I'm capable of secure TLS renegotiation", in case we can get
consensus on signaling this through a ciphersuite ID as well.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 18 Nov 2009 10:59:37 -0800

On 2009-11-18 06:57 PST, [email-masked] wrote:
> should be especially simple to deploy for those clients.  Those clients
> could just include a magic cipher suite number in all client hellos,
> meaning "this is not a renegotiation".

As I read EKR's -01 draft, the magic cipher suite means "IS renegotiation".
You're proposing that the magic cipher suite means  "is NOT renegotiation".
To avoid confusion, I suggest we start explicitly calling it the
"IS renegotiation cipher suite" or the "is NOT renegotiation cipher suite".
Otherwise, confusion may take hold.

> This would be extremely simple to implement,

This is going to be a LOT more code for me (for NSS) than RI was because
it means this new magic number must be special cased EVERYWHERE that cipher
suite numbers are handled.  The code must ensure that the local application
cannot enable it or disable it.  The code must not report it as a supported
cipher suite to the local application.  The code that checks every cipher
suite to see that the necessary crypto algorithms, certs and keys for it
are locally present must not perform those checks for this cipher suite.
The code must ensure at both ends that this suite number never gets
negotiated.  The work to do this is not particularly difficult or complex.
It's just a lot of code strewn all over.

> unlikely to break anything (old servers will ignore it), and could be 
> shipped as soon as we pick the cipher suite number.

> probably need two-way signalling,

Right.  It's signalling the other way that is the potential show stopper
for this proposal.  RI has simple symmetry and doesn't complicate TLS's
protocol versioning scheme at all.  IMO, it is an absolute requirement
of any proposed solution that it not complicate TLS versioning.

> and we need to include the verify_data (or both) from the previous
> handshake somewhere (not necessarily on-the-wire) when doing
> renegotiation.
> 

IMO, no.  We must engineer a complete solution.

---

From: <[email-masked]>
Date: Wed, 18 Nov 2009 20:02:47 +0100

BTW, there's another common renegotiation case where a "low-hanging
fruit" (trivial-to-implement solution known not to cause interop
problems with broken servers) exists: changing from server-only
authentication to mutual authentication (with certificate-based 
cipher suites).

In this case, the client could include a magic "This is a
renegotiation, but with same server certificate" cipher suite in the
renegotiation client hello, and verify that the server certs in the old
and new sessions are identical (bitwise). This would be just a magic
cipher suite number: no other on-the-wire changes, and no changes to
Finished message calculations. But the server would know this
renegotiation is secure, and could proceed even if it prohibited
"old-style" insecure renegotiation.

(In some sense, this is a bit like channel binding with 
'tls-server-end-point' channel binding type.)

This obviously doesn't work when non-certificate-based cipher suites
(like DH_anon) are involved, or when the goal is to actually change
the certificate (probably doesn't make sense in most apps, but could
make for some).

And like the (even simpler) "This is not a renegotiation" magic cipher 
suite, it doesn't allow the client to implement a "strict" policy where 
it refuses to talk (even in initial handshakes) to non-upgraded servers.
But since many servers that don't support renegotiation (either never
did, or have now disabled it), and thus are not vulnerable, will
probably never implement the protocol changes, I'm not sure such a
"strict" policy for clients would ever be usable (except perhaps in
some small and tightly controlled deployments -- which could quite
well implement the "fully featured" solution with TLS extensions).

Best regards,
Pasi
(not wearing any hats)

> From: ext Martin Rex [mailto:[email-masked]]
> Sent: 18 November, 2009 18:48
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 20:10:40 +0100 (MET)

> It's just a lot of code strewn all over.

How about approaching this from a different angle.  You seem
to be several software layer above where this change should go.

The TLS client should add that special ciphersuite ID when composing
the ClientHello handshake message.  This is _NOT_ intended to be
something configurable to applications through regular ciphersuite
selections.

On the TLS server, the code that parses the ServerHello should
recognize this special ciphersuite ID, convert it into a
seperate state variable in the securityparameters of the connection state
and _NOT_ pass it up to software layers above or even higher to
applications between real ciphersuite IDs.

What were doing here is some sort of "compression" on the
handshake information in ClientHello and ServerHello.

The compression code that generate the ClientHello adds the stuff,
the decompression code that parses ServerHello removes the stuff.

I don't mind when you make the information itself available to
the application or configurable to the application, but
_PLEASE_ do not make it through the standard ciphersuite
configuration options, that we have re-purposed here to
get our signaling over the network in existing PDUs.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 20:34:01 +0100 (MET)

> authentication to mutual authentication (with certificate-based 

I'm sure there are plenty of nifty things we can add that
don't need more than a single bit for signaling.

I just wished the designers of TLSv1.0 had replaced the ClientHello
extensibility that was present in SSLv3 already (at least in the
spec that happened after the implementations)

   Forward compatibility note:
       In the interests of forward compatibility, it is permitted for a
       client hello message to include extra data after the compression
       methods. This data must be included in the handshake hashes, but
       must otherwise be ignored. This is the only handshake message for
       which this is legal; for all other messages, the amount of data
       in the message must match the description of the message
       precisely.

already in 1998 with a uint32 plus optional yet-to-be-defined data
and added this to the ServerHello as well.  Then there would be
an easy-to-use bitfield from one could draw bit-flags -- and the
extensions-intolerance would have been ironed out by know.

The TLS extension mechanism is pretty heavyweight.

I find it somewhat strange for the IETF to adopt a handshake protocol
with pretty much no slack (TLSv1.0).

(buzzwords like "side-channel" or "covert-channel" are a total non-issue
 here.  Both ClientHello and ServerHello contain 60 octets of data
 (64 octets if you randomize gmt_unix_time) that is specified and
 allowed to look random, and a ciphersuite list where you can
 use perfectly valid (but frowned upon) integrity-only ciphersuites
 for signaling (you could also signal by the sequence of the
 ciphersuites...), and then client and server can use the space
 of the 60/64 random octets in ClientHello and ServerHello to
 exchange arbitrary data.  And when they encrypt this data, it will
 even look less suspicious!)

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 18 Nov 2009 14:24:13 -0600

> ignore it), and could be shipped as soon as we pick the cipher suite

Perhaps they could simply advertise support for the fix with no other
implementation changes. If they really don't support renegotiation, then
they'll never have to exchange data under whatever modified method is
used to enforce the binding.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Nov 2009 22:01:45 +0100 (MET)

> I really believe that's the place for the server to signal.

What we're trying to do is to compress more information into
the original (SSLv3) ServerHello data structure than the original
designer provided room for.

What is an engineer going do when given the task to transport
some information in a container that is shorter than the information?

Compression comes to mind.  Which parts of the ServerHello are
compressible?

ServerHello.server_version is a container of 16 bits,
and all information it had to carry in its life so far is like
2.something bits.

Since the value range of server_version is tightly controlled
(by the maintainers of the specs), we're not going to run into
accidental collisions.

The problem with the randoms is, that they're not compressible.
we can not prevent accidental collisions.

In theory, the gmt_unix_time had been a good candidate with
a predictable collision probability -- just that some implementors
seem to have goofed this idea by randomizing the content.

The correct approach to not leak your exact clock would have
been to fuzz the seconds.  E.g. use a random but fixed bias
(the lowest 8-16 bits) and select a new random bias
every couple of hours.  This would have left the
collision probability predictable in case someone needs
to re-purpose that field in the handshake message.

I would consider fuzzing the lower part of gmt_time_unix still
within the spec (bending a little bit, but still in the spec).

Replacing it with entirely random data is breaking the spec,
and it is where most of the interop problems in our protocols
come from.   Bending a spec when you have a justification
is OK, breaking the spec is not.

>
> As for the client signal, the fake ciphersuite is clean and
> not-elegant-but-ok.  However, for no reason other than aesthetics, the
> client signal should be similar to that of the server. And I'd use two
> magic values:
>  - SAFE - (server only) Renegotiation is disabled. This allows a quicker
> fix. Not sure if this is really needed, though.
> 

In theory the two values sound nice,  In practice they do not necessarily
make a difference.

All of the handshake data is only protected by the finished messages,
(plus the CertificateVerify when a client certificate is used).

In principle, what were trying to "negotiate" is the information
from the client "I don't like to get screwed with the old TLS renego"
and the confirmation from the server "I'm not going to screw you
with the old TLS renego" and the finished message verification will
determine whether client and server actually sent what each other
received (no attacker doctoring the messages).

Before either communication peer has not verified the others
finished messsage (CertificateVerify can also authenticate
the initial part of the handshake, but be careful about premature
conclusions!!), _no_ part of the TLS handshake should be considered
authentic.  You can detect some modifications earlier, but without
finished message verification you not make any assumptions.

-Martin

---

From: Robert Relyea <[email-masked]>
Date: Wed, 18 Nov 2009 14:18:48 -0800

> something configurable to applications through regular ciphersuite

What bothers me about this whole line of reasoning is we are abusing
well defined fields to work around the fact that some implementations do
not support the standard way of extending (that is extensions).

I see this as wrong because:

1) We already need to use extensions to get other important features in
TLS (the most notable is SNI).
2) This rewards people who have blatantly ignored the spec --- for
years. (the use of extensions is not new. People have had close to a
decade to fix their issues).
3) We are depending on friendly behavior from toolkits that cannot
correctly implement 'ignore anything after this byte' in the spec.
4) Well structured code is designed to handle extensions. Repurposing
fields will almost certainly punish well structured code.

Clients have already developed solutions so they can use extensions in
our ecosystem. Cleaning out servers that cannot handle them by marking
them as insecure is a good thing.

In short this proposal rewards bad implementations and rewards good ones.

bob

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Nov 2009 15:07:09 -0800

Martin Rex wrote:
>> This is going to be a LOT more code for me (for NSS) than RI was ......
> 

That is how I implemented it in my code.  There is no configuration
to turn it off, since that would be unnecessary.  The code that creates
the ClientHello simply prepends the special ciphersuite to the list.

> applications between real ciphersuite IDs.

And I did this too.  The code that parses the client's list of cipher
suites looks for the special value and sets a flag when it sees it.  It
is not put in the list of ciphers passed to the cipher suite selection
code.

Mike

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 19 Nov 2009 13:22:38 +1300

Martin Rex <[email-masked]> writes:

>If you are referring to the SSLv2 backwards-compatibility option, that seems
>to be actually still used in Firefox 3.5 in the automatic reconnect fallback
>should the server choke on TLS extensions.

The last time I checked it was *always* used, not just as a fallback option.
In other words Firefox will always send an SSLv2 hello if SSLv3 is enabled. If
you disable SSLv3 (so only TLS is enabled) then it finally stops sending the
SSLv2 hello, but at that point something else breaks, a failed handshake can't
be retried any more.  In other words if you try to connect to foo.com and
there's a packet loss or timeout or something similar then any subsequent
attempt to connect will instantly fail, until you shut down the browser and
restart it.

(This was up until about a year ago, so before 3.5, I haven't checked 3.5).

Peter.

---

From: Chris Newman <[email-masked]>
Date: Wed, 18 Nov 2009 16:29:34 -0800

> well implement the "fully featured" solution with TLS extensions).

I want a standardized protocol mechanism that allows a TLS server to assert 
to my TLS client it is not vulnerable to the renegotiation attack.  The 
vulnerability does not concern me for lower security transactions (like 
credit card payments) so I'll never want a client to reject all servers 
lacking the indicator, but it does concern me for higher security 
transactions (like money transfers) so as a user I need to know.  There are 
institutions I must deal with where I can not trust a statement from their 
customer service asserting their servers are not vulnerable (the customer 
service personnel are incented to say what I want to hear to get me off the 
phone).  However, if my client software gets a standardized assertion from 
their server software, I would consider that an acceptable trust level for 
higher security transactions.

The RI extension provides acceptable signaling from the server to address 
this customer requirement.

		- Chris

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 19 Nov 2009 00:46:45 +0000

> (This was up until about a year ago, so before 3.5, I haven't checked 3.5).

OpenSSL used an SSLv2 compatible client hello until very recently unless
extensions were supported/required. The 1.0.0 version uses SSLv3 compatible if
all SSLv2 ciphersuites are disabled (they are by default in 1.0.0).

Steve.

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 18 Nov 2009 17:55:12 -0800

On 2009-11-18 16:22 PST, Peter Gutmann wrote:
>> If you are referring to the SSLv2 backwards-compatibility option, that 
>> seems to be actually still used in Firefox 3.5 in the automatic 

No.  SSLv2 compatible hellos are used only in fallback.  It's been that way
ever since fallback was introduced.

> In other words Firefox will always send an SSLv2 hello if SSLv3 is 
> enabled.

No.  Once Firefox has found that it cannot connect to a particular server
with TLS, but can connect to that server with SSLv3, then for the remainder
of the process lifetime, or until the process SSL protocol options are
changed, it will remember that that server does not speak TLS, and will not
thereafter try to speak TLS to that server.

> If you disable SSLv3 (so only TLS is enabled) then it finally stops
> sending the SSLv2 hello,

Whenever you change the SSL/TLS protocol options, it resets the memory of
several things.  (Flushes the SSL/TLS session cache, IIRC, among other things.)

> but at that point something else breaks, a failed handshake can't be 
> retried any more.

If TLS is the only option it has (because all others are disabled) and
TLS fails, then it doesn't try anything else.  That's what you'd expect.

> In other words if you try to connect to foo.com and there's a packet loss
> or timeout or something similar then any subsequent attempt to connect
> will instantly fail, until you shut down the browser and restart it.

There were some versions of Firefox that had such a bug, yes.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 19 Nov 2009 03:56:37 +0000

> "old-style" insecure renegotiation.

I don't see the advantage. The client has changed something, therefore
it is patched. The server has recognized the change, therefore it is
patched. So why are they unable to interoperably perform a "new-style"
secure renegotiation? There is no benefit to introducing additional cases
just because a change to the Finished calculations *could* be avoided here.

(It's actually not clear to me that it can be securely avoided if the
server has a wildcard certificate.)

> well implement the "fully featured" solution with TLS extensions).

Support for the strict-client policy is non-negotiable :-) as far as I'm
concerned.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 20 Nov 2009 19:37:39 +1300

<[email-masked]> writes:

>BTW, there's another common renegotiation case where a "low-hanging fruit"
>(trivial-to-implement solution known not to cause interop problems with
>broken servers) exists: changing from server-only authentication to mutual
>authentication (with certificate-based cipher suites).

What TLS does with certificates isn't mutual authentication, it's
unidirectional authentication in both directions.  TLS-PSK provides true
mutual authentication.  So perhaps the fix is to encourage people to switch to
TLS-PSK, which as a side-effect would do a great deal to address the phishing
problem as well.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 18:58:18 +0100 (MET)

> "old-style" insecure renegotiation.

When there really is a desire to add a few simple signals in
a (probably) fully backwards compatible fashion into all existing
TLS&SSL protocols through magic ciphersuite,

Then I would like to suggest the following approach:

 - have an entire range (set of 256 ciphersuites) assigned for
   this purpose (e.g. first byte 190/0xBE or 191/0xBF )

 - use the low byte of this range as a bitfield of 8-bits
   for signaling that can be independently assigned by TLS WG / IANA

 - require this magic ciphersuite to be first in the cipher_suites
   list of the ClientHello if this signaling facility is to be used

 - require the Server to NOT ever negotiate a ciphersuite from this range
   i.e. remove it from the list when it appears first in
   ClientHello.cipher_suites and do not pass it on to functions
   that determine a common cipher suite with the client.

 - strongly recommend clients and servers to filter this magic
   ciphersuite range from normal cipher suite configuration APIs

-Martin