Subject: [TLS] Deprecating SSLv3

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Nov 2014 15:17:50 -0800

(UTA on BCC)

The POODLE attack has been used across the industry to justify disabling SSLv3.

For some of us, this was just the excuse, but others might need more
motivation.  A statement from the IETF might help move some people.

Richard, Alfredo, Adam and I have proposed such a statement:

https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/

---

From: Matt Caswell <[email-masked]>
Date: Tue, 11 Nov 2014 09:28:32 +0000

> https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/

This sentence gave me pause for thought:

"Servers SHOULD accept handshakes from clients that propose SSLv3 or
higher, but MUST NOT negotiate SSLv3"

I found that quite a confusing sentence and had to read it a couple of
times. The "or" suggests that "servers SHOULD accept handshakes from
clients that propose SSLv3 (only)"...and then goes on to contradict itself.

Perhaps something like

"Server SHOULD accept handshakes from clients that use a record layer
version of {03,00} (SSLv3), but MUST NOT negotiate SSLv3"

Matt

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Nov 2014 11:06:17 -0800

> version of {03,00} (SSLv3), but MUST NOT negotiate SSLv3"

Thanks.  I will make that change.

https://github.com/unicorn-wg/sslv3-diediedie/pull/10

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 11 Nov 2014 21:27:58 +0100

> https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/
Thanks for your work on this! I'm very sympathetic to the goal, but I'm a bit
puzzled by the following statement:

                                                   Clients MUST NOT set
   a record layer version number (TLSPlaintext.version) of {03,00}.
   Clients SHOULD offer their highest supported version (that is, the
   same value that appears in ClientHello.client_version); though
   clients MAY use any value greater than or equal to the lowest version
   number they are willing to negotiate.  Servers SHOULD accept
   handshakes from clients that propose SSLv3 or higher, but MUST NOT
   negotiate SSLv3.

The underlying assumption between the first sentence seems to be that
TLSPlaintext.version somehow indicates the lowest version that the client is
willing to negotiate. The last sentence also seems to imply the server knows the
range of versions the client is willing to use (as opposed to just the highest
version), which seems to confirm that.

Is there already something in the standard that says that the client offers a
range of versions by using TLSPlaintext.version for the lower bound in addition
to ClientHello.client_version? I didn't find it, so I'm worried about
(implicitly) introducing new semantics about version negotiation in this document.

Also, I'm curious about the reason why clients SHOULD "offer" the same version
in TLSPlaintext.version as in ClientHello.client_version: first, I'm not sure
what purpose it serves. Second and more importantly, isn't there a risk of
introducing new intolerance issues? This is an actual question, if you have the
answer and it's no, I'm delighted.

Manuel.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Nov 2014 13:07:25 -0800

> (implicitly) introducing new semantics about version negotiation in this document.

That's a fair point.  We probably shouldn't do that, yes.  Maybe a
removal of the first sentence would suffice for that.

TLS basically disavows all claims regarding what goes in the
ClientHello.  We do know slightly more today such that we might be
able to fix it, but I don't think we need to open that can of worms
here.  That certainly wasn't the intent.

---

From: Stephen Checkoway <[email-masked]>
Date: Tue, 11 Nov 2014 17:40:23 -0500

> https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/

Is there any harm associated with having 03 00 in the record layer? It seems like the three statements you want are:

1. The client MUST NOT send a ClientHello with ClientHello.client_version set to { 3, 0 }.
2. The server MUST NOT send a ServerHello with ServerHello.server_version set to { 3, 0 }.
3. If the client receives a ServerHello with ServerHello.server_version set to { 3, 0 }, the client MUST send a "protocol_version" alert message and close the connection.

I think these three are sufficient to forbid negotiating SSLv3 and the advice given in Appendix E still applies:

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

1 isn't necessary as long as you have 3, but it seems pointless to have ClientHello.client_version = { 3, 0 } and then close the connection.

The current draft seems to allow the following two scenarios where the client adheres to the draft but the server does not.

Scenario I:
TLSPlaintext.version = { 3, 1 }
ClientHello.client_version = { 3, 0 }
ServerHello.server_version = { 3, 0 }

Scenario II:
TLSPlaintext.version = { 3, 1 }
ClientHello.client_version = { 3, 1 }
ServerHello.server_version = { 3, 0 }

The first scenario is pretty unlikely (why would the client be compliant with the draft but have a maximum version of SSLv3?) but would seem to work with a TLSv1.2 server that was willing to negotiate SSLv3.

The second scenario seems more likely with a SSLv3 server (which accepts 03 xx in the record layer).

Maybe I'm missing something that rules those two cases out. But even if so, a clear MUST NOT regarding the client_version and server_version and a MUST on the protocol_alert if the server wants SSLv3 seems better overall.

-- 
Stephen Checkoway

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 16 Nov 2014 13:21:46 -0500 (EST)

----- Original Message -----
> here.  That certainly wasn't the intent.

Will that be included in the draft? There is no point to have:
"Clients MUST NOT set a record layer version number (TLSPlaintext.version) of {03,00}."
as it will make perfectly valid TLS 1.2 client non compliant with the
draft for no apparent reason (if there is a reason for that please elaborate
in the draft).

Other than that, if that is fixed, no objections.

regards,
Nikos

---

From: Alfredo Pironti <[email-masked]>
Date: Sun, 16 Nov 2014 23:22:29 +0100

On Sun, Nov 16, 2014 at 7:21 PM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> Will that be included in the draft?

Yes, I agree this is a fair point. I'll complete the wording tomorrow in
the pending PR, and these ideas will get into the updated version.

Cheers,
Alfredo

> There is no point to have:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 21 Nov 2014 16:43:25 +0100

On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote:

> Yes, I agree this is a fair point. I'll complete the wording tomorrow
> in the pending PR, and these ideas will get into the updated version.

Some additional comments:
1. It has quite awkward structure. The main body of the document is at
the introduction section.

2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be
permitted."
Not sure I understand what it means. Does it mean that fallback to SSL
3.0 from any version of TLS MUST NOT be permitted?

3. The document doesn't provide any instructions for clients that have
no other way to communicate with a server that only supports SSL 3.0.
MUST NOT is nice in theory, but can only be enforced on the systems one
has control on, and if the advise is followed to the letter legacy
systems (not talking of web) will be only be accessible in plaintext.
I'd expect prohibiting the fallback dance instead, and requiring that
SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the
clientHello.

regards,
Nikos

---

From: Ronald del Rosario <[email-masked]>
Date: Fri, 21 Nov 2014 16:22:01 +0000

+1

Ron F. del Rosario
Information Security Officer

Five9, Inc.
Cloud Contact Center Software

From: Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 21, 2014 at 7:43 AM
To: Alfredo Pironti <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] Deprecating SSLv3

regards,
Nikos

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

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Alfredo Pironti <[email-masked]>
Date: Fri, 21 Nov 2014 23:35:25 +0100

Hi Nikos,

Thanks for your further comments. I'm answering to them inline.

> the introduction section.

The structure can certainly be reworked once further consensus is reached,
and hence the text stabilizes. I expect that some further editorial work
may be required anyway if the draft proceeds forwards.

> 3.0 from any version of TLS MUST NOT be permitted?

Well, the idea is that once SSLv3-only software is eradicated, then only
TLS implementations capable of running SSLv3 will remain. Those should not
negotiate SSLv3, even if they're able to do so. Anyway, most of this text
is being recently reworked to be clearer and fix the Record layer potential
interop issues you and others have already noted. See for instance the
proposed draft [1].

> systems (not talking of web) will be only be accessible in plaintext.

My understanding is that MUST NOT is the way legacy protocols usage is
prohibited, see for example SSLv2 deprecation [2], which uses a very
similar terminology. Of course closed systems will be free to ignore this
document and still negotiate SSLv3 (or v2, for that matters). But yes, I'd
claim the whole purpose of this draft is to outlaw (and encourage to update
to TLS, not to retrofit to plaintext) open systems that connect to the
Internet.

> SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the

I'd keep fallback out of the scope of this document, as the so notorious
fallback dance has never been part of the TLS protocol negotiation itself.
And, certainly, I wouldn't advocate fallback (even straight SSLv3
negotiation could be used as a last-resort fallback by some) to still
support negotiation of SSLv3 for systems that don't really bother to
upgrade to TLS almost 15 years after it was specified.

Best,
Alfredo

[1] https://github.com/unicorn-wg/sslv3-diediedie/pull/10
[2] http://tools.ietf.org/html/rfc6176

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Nov 2014 14:29:28 -1000

On 21 November 2014 12:35, Alfredo Pironti <[email-masked]> wrote:
> prohibited, see for example SSLv2 deprecation [2], which uses a very similar
> terminology. Of course closed systems will be free to ignore this document
> and still negotiate SSLv3 (or v2, for that matters). But yes, I'd claim the
> whole purpose of this draft is to outlaw (and encourage to update to TLS,
> not to retrofit to plaintext) open systems that connect to the Internet.

Yes, I would be sad if we couldn't say anything more definitive about
the use of TLS on the big 'I' Internet.  People are of course welcome
to use rot13 to protect their proprietary communications, noting that
they won't remain proprietary long if they do.  The same applies here.

I merged Alfredo's text, and though I've proposed some minor
grammatical changes, you can see the results live here:
  https://unicorn-wg.github.io/sslv3-diediedie/

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 22 Nov 2014 05:40:27 -0500 (EST)

----- Original Message -----
>   https://unicorn-wg.github.io/sslv3-diediedie/

I believe that comparison is way out of proportion, for the following reasons:
* First SSL 3.0 is still in use - at least my experience shows many
SSL 3.0 only services on a typical network (it did only take few hours to get
the first bug report when SSL 3.0 was disabled in the development branch of Fedora),
* there is no new attack on SSLv3 (the attack poodle uses on SSLv3 was already known 10
years ago), and the TLS protocol negotiation is still considered secure enough to
negotiate the latest version supported between two parties
* SSLv3 is orders of magnitude better than plaintext (or rot13).

The latter shows the actual dilema many face at the moment, which is not whether to replace 
SSL 3.0 with TLS 1.2, but what to do to interoperate with the services that can only use 
SSL 3.0 or plaintext. You may choose to ignore them of course but that would also render
that draft not applicable to them.

Note here that I am not advocating the use of SSL 3.0, but it would be beneficial for 
everyone if that draft also described a path which leads to the abolishment of SSL 3.0
in a secure way, for the ones that cannot avoid its use. That highlights the main difference 
with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it was published.

regards,
Nikos

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 22 Nov 2014 11:56:59 +0100

On Sat, Nov 22, 2014 at 05:40:27AM -0500, Nikos Mavrogiannopoulos wrote:
> That highlights the main difference 

There still are SSLv2 only services on the internet.  Hubert Kario
last scan results
(https://lists.fedoraproject.org/pipermail/security/2014-October/001989.html)
said:
Supported Protocols       Count     Percent
-------------------------+---------+-------
SSL2                      44800     10.2755
SSL2 Only                 5536      1.2698
SSL3                      302890    69.4723
SSL3 Only                 2971      0.6814

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 22 Nov 2014 11:42:00 -0500

> * First SSL 3.0 is still in use - at least my experience shows many SSL 3.0 only
> services on a typical network (it did only take few hours to get the first bug

Sure, there are lots of deployments.  We see it too.  (Well, not lots; significantly under 1% by connections.)

But that does not mean it is the best practice.  Sometimes you just can't be the best.  I'll never win a medal at the Olympics, but that doesn't mean that other folks should never be able to set world records.

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 24 Nov 2014 09:16:29 +0100

> Supported Protocols       Count     Percent

I believe that this shows more about issues with the sample of the test
rather than functioning SSLv2 only servers. Given that there is no way
to connect to them anyway, they could be misconfigured non functional
servers or honeypots. 

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Mon, 24 Nov 2014 13:18:56 +0100

On Monday 24 November 2014 09:16:29 Nikos Mavrogiannopoulos wrote:
> > > with SSL 2.0 and rfc6176; there were no SSL 2.0-only services when it
> > > was published.> 
> > (https://lists.fedoraproject.org/pipermail/security/2014-October/001989.ht
> > ml) said:

This is actually a result of their intolerance to SSLv3 ClientHello with large 
amount of ciphers (or RC4 placed after 64th position in the list - the win 2k3 
TLS bug).

I've extended the scanner to try more fallbacks when testing (retry with a 
much smaller client hello) and the stats for this month look like this:

Supported Protocols       Count     Percent
-------------------------+---------+-------
SSL2                      38835     8.7934
SSL2 Only                 100       0.0226
SSL3                      204062    46.2059
SSL3 Only                 2195      0.497
SSL3 or TLS1 Only         108575    24.5847
SSL3 or lower Only        2293      0.5192
TLS1                      438481    99.2856
TLS1 Only                 46428     10.5127
TLS1 or lower Only        143729    32.5447
TLS1.1                    281522    63.7453
TLS1.1 Only               25        0.0057
TLS1.1 or up Only         443       0.1003
TLS1.2                    292517    66.2349
TLS1.2 Only               337       0.0763
TLS1.2, 1.0 but not 1.1   13585     3.0761

(the script managed to connect to about 100 more servers with even smaller
client hello, most of which accepted just v2-compatible client hello, but I've 
not implemented the scan for such intolerant servers yet)

I think we can safely banish a protocol that only 0.5% of servers require for
interoperability.

Regarding the SSLv3 MUST NOT: we have to remember that we're talking about a 
security protocol *used* for security. In such context SSLv3 should not be 
used.

Just like MD5 use for digital signatures is completely broken but is 
completely fine to use it as a checksum to verify proper download of a file 
over internet (people use CRC32 for that!), use of SSLv3 for interop is fine, 
but not if it is used for confidentiality.

+1 to MUST NOT
-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Nov 2014 16:59:35 +0100 (CET)

> Supported Protocols       Count     Percent

How do TLS extension support fit into your picture?

Just a few days ago I was working on a customer message about interop
problems with a Business-2-Business scenario, and the Server that is used
seems to be an extensions-intolerant TLSv1.0 server.  The server is OK
with ClientHello.client_version = { 3, 3 }, but when ClientHello includes
any TLS extensions, it will abort with a fatal unexpected_message(10) alert.

 (the Website is http://www.elemica.com,
   the service(s) are on https://preprod.connect.elemica.com:5443
                     and https://connect.elemica.com:5443
   authentication is by TLS client certificate, but you'll see the
   TLS extensions intolerance by the fatal alert response to ClientHello.

> I think we can safely banish a protocol that only 0.5% of servers require for

Maybe you can, but I can not.  The support load would still be prohibitive.

> but not if it is used for confidentiality.

You might not be aware of it, but there is only one TLS protocol version
that allows digital signatures with md5WithRsaEncryption, and that is TLSv1.2.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Mon, 24 Nov 2014 17:32:45 +0100

> How do TLS extension support fit into your picture?

I don't know.

That is: I'm using openssl command line binary (albeit with few changes, 
modifications and additions compared to upstream) and as such I don't believe 
I can send TLS1.0/1.1/1.2 Client Hello without extensions.

In other words, all those servers that report TLS1.0 as supported mean also 
support for typical extensions (server_name, curves, signature_algorithms, 
etc.). The amount of servers which are TLS extension intolerant and either 
have SSLv3 disabled or are V2 client hello compatible is under 0.1%.

What I have no idea about is the amount of servers that are V2 ClientHello 
*and* TLS-extension intolerant.

> > I think we can safely banish a protocol that only 0.5% of servers require
> > for interoperability.
> 

In the case you're talking about you can connect using TLS1.0 without 
extensions, and while that is suboptimal in general it is allowed under 
current draft (and supported with TLS_FALLBACK_SCSV).

Anyway, you should file a complaint to the manufacturer that it haven't 
addressed the POODLE vulnerability in their product (or that it doesn't 
implement advertised protocols properly).
If you don't have a contract under which you can do that or can't change the 
TLS library yourself, you have much bigger problems anyway...
 
> > Regarding the SSLv3 MUST NOT: we have to remember that we're talking about
> > a security protocol *used* for security. In such context SSLv3 should not
> > be used.
> > 
> > over internet (people use CRC32 for that!), use of SSLv3 for interop is
> > fine, but not if it is used for confidentiality.
> 

yes, I am aware about that. Quite a few servers will in fact happily sign the 
key exchange with MD5. But that will happen only if the client advertises 
support for it (I did found 3 that will sign using only MD5 but I haven't 
checked if it's not a false positive). And most will fallback to either non 
(EC)DHE cipher or just force SHA1 on the client if it doesn't advertise RSA 
key signature algorithms.

-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Nov 2014 18:06:22 +0100 (CET)

Hubert Kario wrote:
> Martin Rex wrote:

When I tested with https://preprod.connect.elemica.com:5443/
I realized that the openssl s_client tool has become somewhat unusable,
because it includes a lot of TLS extensions in client hello without
being asked to do so and also without a command line option to have it stop
doing this.

openssl-0.9.8y with "openssl s_client -no_ticket" seems to be able to
produce an extension-free TLSv1.0 ClientHello.

> implement advertised protocols properly).

What are you talking about?

Poodle is a *PURE* Web-Browser and client problem.
Servers are not vulnerable to Poodle, and this site *REQUIRES*
TLS client certs for authentication.

Disabling SSLv3 on servers is only a practical mitigation against
the stupid "downgrade dance" that so many browsers perform.
It's difficult for me to understand how someone could implement
the downgrade dance and *NOT* provide a switch to turn it off after
addressing the rfc5746 tls renegotiation issue.

-Martin

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 24 Nov 2014 18:18:31 +0100

> Poodle is a *PURE* Web-Browser and client problem.

I'm not sure I agree with that.  But it is by far the most easy
way to exploit it.

Kurt

---

From: Hubert Kario <[email-masked]>
Date: Mon, 24 Nov 2014 18:43:13 +0100

> addressing the rfc5746 tls renegotiation issue.

To exploit POODLE you need fallback dance *or* support just SSLv3. It's not 
limited to web browsers (and there are some clients that do fallback and are 
not browsers, e.g. curl).

Also, are you saying that an *automated* system won't retry on connection 
failure?

We're talking about average of 128 failed requests per byte decrypted, even if 
we fail just every first connection on a system that queries remote server 
every 5 minutes 24/7 that will require just a month to decrypt 16 byte 
password/authentication string. There have been far more dedicated and longer 
attacks in the wild.

SSLv3 has known security problems, more issues may be discovered in the 
future... or not (as the researchers may decide that it was thus completely 
broken and as such not worth investigating further). So while use of 
certificates may mitigate this problem, we may not ever know if it mitigates 
all problems SSLv3 has. For example, issues like 3-shake won't be fixed in 
SSLv3. In my opinion, continued use of it for security-critical applications 
qualifies for gross negligence.

Do we really need the repeat of the MD5 signatures story or can we learn on 
our own (as in industry) mistakes?
-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Nov 2014 19:29:53 +0100 (CET)

> Also, are you saying that an *automated* system won't retry on connection 

_very_ few, if any.  Exactly none of ours.

> 
> We're talking about average of 128 failed requests per byte decrypted,
> even if we fail just every first connection on a system that queries
> remote server every 5 minutes 24/7 that will require just a month to
> decrypt 16 byte password/authentication string. There have been far
> more dedicated and longer attacks in the wild.

You may have not understood the Problem.

It's a plaintext recovery of 1 byte per 256 requests on average
and you can only recover the last byte of any CBC ciphertext block,
not the other 7 (3DES/IDEA) or other 15(AES).  And you will need a
high probability that the secret you want to recover is at a static
position of the requests that you're attacking.

A poodle attack will be pretty "noisy" on the server, so for many
usage scenarios, this will be sufficient deterrent, just like many
apartments have no bullet-proof windows and many doors have not
pick-proof locks.

And you could add random URL-parameters or other insert additional
header fields before the credentials if you absolutely want to
keep doing disclosing authentication rather than simply switching
to using TLS client certs for the requests.

> 
> SSLv3 has known security problems,
> more issues may be discovered in the future.

TLS has long known weaknesses and well-documented limitations.

When you remain within the safe usage areas, even SSLv3 is still secure.

Really, what we should worry about is the current usage scenarios
where even TLSv1.2 can not provide protection, and one of these
is Cross-Site-Request-Forgery as currently offered by Web-Browsers.

>
> So while use of certificates may mitigate this problem, we may not
> ever know if it mitigates all problems SSLv3 has.

I'm not expecting any. Honestly.

>
> For example, issues like 3-shake won't be fixed in SSLv3.

I never offered TLS renegotiation to applications in our implementation,
and I hardwired it to a fatal alert on the server in 2010.

Conservative designs don't have to care about 3-shake.

There are several more implementation pitfalls hidden in the
TLS renegotiation design.

>
> In my opinion, continued use of it for security-critical applications 

Nope.  Continued offering of SSLv3-only is the problem here.
The original SSLv3 and TLS design protects the security parameters
of the TLS handshake, so a TLSv1.0 capable client that does not
send ClientHello.client_version = { 3,1 } (or can be coerced to not
signale TLSv1.0 support by a network-based attacker) is the problem.

> our own (as in industry) mistakes?

It would already be an improvement if the TLS WG stopped (mostly) ignoring
problems (such as Vaudenay's), or didn't add new problems (such as
making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm).

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Mon, 24 Nov 2014 20:35:45 +0100

On Monday 24 November 2014 19:29:53 Martin Rex wrote:
> > limited to web browsers (and there are some clients that do fallback and
> > are not browsers, e.g. curl).
> > 

we're not writing the RFC for your systems only
 
> It's a plaintext recovery of 1 byte per 256 requests on average

no, you need 256 for 100% chance of recovery, statistically speaking you need 
128 requests for a 50% chance of recovery - 50% *is* average, especially if 
we're talking about recovering multiple bytes.

> apartments have no bullet-proof windows and many doors have not

attacks are unlikely (in general), administrator will consider hardware 
failure or a software bug before an active attack

that is *if* he will look in the logs at all...
 
> to using TLS client certs for the requests.

that means implementing mitigations. You might as well stop using 18 years old 
protocol while you're making changes to your application code

> is Cross-Site-Request-Forgery as currently offered by Web-Browsers.

just because other systems have issues doesn't make this particular problem 
smaller
 
> I'm not expecting any. Honestly.

a protocol that requires 2 pages to describe all the pitfalls and workarounds 
needed to use securely is a bad protocol

that basically makes it impossible to implement and use securely

> TLS renegotiation design.

you did that, how many did not? have you peer reviewed your changes? can you 
trust those reviews? (see also: CloudFlare Challange)

and let me repeat myself: we're not making RFC for your implementation only
  
> making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm).

Sorry, but that is simply not true.

The specified behaviour is to select SHA1 in case the client doesn't provide 
the extension. At no point the RFC says that RSA+MD5 is a MUST or even SHOULD.

-- 
Regards,
Hubert Kario

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 24 Nov 2014 21:12:03 +0100

> I can send TLS1.0/1.1/1.2 Client Hello without extensions.
I'm not sure how (in)convenient it would be for you to use another tool in
addition, but gnutls-cli allows that easily: just add %NO_EXTENSIONS to the
priority string.

http://gnutls.org/manual/html_node/Priority-Strings.html#tab_003aprio_002dspecial1

Manuel.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Nov 2014 12:57:01 -0800

> apartments have no bullet-proof windows and many doors have not

What part of "don't hack from your own machine" do you think the NSA
doesn't understand? Even if you noticed the attack, and it isn't from the
government,  what deterrence is there? There was more law and order in the
Wild West.

> When you remain within the safe usage areas, even SSLv3 is still secure.

Trivial statement is trivial. What are the safe use areas exactly?

> Conservative designs don't have to care about 3-shake.

Why does a protocol like TLS have options to shoot yourself in the foot?
Also, I seem to recall quite a bit of discussion of how renegotiation was a
simple and elegant feature when the suggestion to remove it was made. I
suppose it is when you hardwire it to fail.

Conservative protocol designs minimize options and ensure that the easiest
option is the secure one. They stress simplicity of implementation to ease
auditing implementations, and thus are codesigned with an implementation.
Features are bugs.

> TLS renegotiation design.

Care to share? Or when these are exploited widely, will you insist they
were well-understood limitations?

> making (rsa,md5) a mandatory-to-implement TLSv1.2 signature algorithm).

And by depreciating a protocol version that doesn't use a secure record
layer because of Vaudenay's attack we are responding to the problem.
Vaudenay's padding oracle is exploited in Lucky 13. Any response is going
to involve depreciating protocols because of well-understood limitations.

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 15:30:54 -0600

On Mon, Nov 24, 2014 at 12:57:01PM -0800, Watson Ladd wrote:
>              [...]? Even if you noticed the attack, and it isn't from the
> government,  what deterrence is there? [...]

And/or what mitigation...

Bearer tokens are currently, and for the forseeable future, a fact of
life.  An annoying fact of life, maybe, but one that we must accept.

Surely that can't be controversial.

TLS 1.3 simply must be resistant to adaptive chosen plaintext attacks
intended for recovery of frequently repeated secrets (bearer tokens).

To be fair to Martin R., I suspect he's not objecting to this, so much
as to the use of bearer tokens in the first place, much as I'm objecting
to blaming TLS's past failures on the Internet threat model while... not
being against updating the Internet threat model.  That we can't fix the
bearer token problem from where we stand doesn't mean that Martin can't
complain about it...

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Nov 2014 00:29:41 +0200

> On Nov 24, 2014, at 11:30 PM, Nico Williams <[email-masked]> wrote:
> ]
> as to the use of bearer tokens in the first place, 

I don’t know about Martin, but the thing that bothers me most about cookies is not that they’re bearer tokens or that they’re a lucrative target for attacks, but the fact that they can freely be used by attackers.

CRIME, BEAST, POODLE, they all depend on my browser going to http://www.attacker.com, and then a script loaded from that site running on the browser, sending requests to Facebook and google and the like with *my* cookies. For some reason these requests are treated as if they come from *me* rather than the attacker. They call it CSRF, but it’s not really forgery. It’s just the way the web is built.

If I had to choose between “new cookie” that is not a bearer token but is somehow bound to session or origin and a “new cookie” that is scoped so that only scripts loaded from *.google.com can use my google.com cookie while other scripts send unauthenticated requests, I’d choose the scoping.

Yoav

---

From: Bill Frantz <[email-masked]>
Date: Mon, 24 Nov 2014 14:44:22 -0800

On 11/25/14 at 2:29 PM, [email-masked] (Yoav Nir) wrote:

>If I had to choose between “new cookie” that is not a 
>bearer token but is somehow bound to session or origin and a 
>“new cookie” that is scoped so that only scripts loaded 
>from *.google.com can use my google.com cookie while other 
>scripts send unauthenticated requests, I’d choose the scoping.

That scoping is approaching a capability system. If the 
authority and the object which recognizes that authority are 
bound together in one reference, then you have a capability. The 
closest we get to capabilities on the web are OATH tokens and 
URLs with "unguessable" strings.

A good capability system allows references to be transferred 
between people/programs to allow rich sharing 
<http://www.skyhunter.com/pubshare/>. Rich sharing can greatly 
reduce the incentive to share usernames and passwords.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | I don't have high-speed      | Periwinkle
(408)356-8506      | internet. I have DSL.        | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 16:45:05 -0600

On Tue, Nov 25, 2014 at 12:29:41AM +0200, Yoav Nir wrote:
> I don’t know about Martin, but the thing that bothers me most about
> cookies is not that they’re bearer tokens or that they’re a lucrative
> target for attacks, but the fact that they can freely be used by
> attackers.
> 
> CRIME, BEAST, POODLE, they all depend on my browser going to
> http://www.attacker.com, and then a script loaded from that site
> running on the browser, sending requests to Facebook and google and
> the like with *my* cookies. For some reason these requests are treated
> as if they come from *me* rather than the attacker. They call it CSRF,
> but it’s not really forgery. It’s just the way the web is built.

Oh sure, and I agree fully, we could totally have a bash-the-web-
security-model thread :) but we can't really do anything about it from
TLS WG.

> If I had to choose between “new cookie” that is not a bearer token but
> is somehow bound to session or origin and a “new cookie” that is
> scoped so that only scripts loaded from *.google.com can use my

And DOM elements (but I repeat what you said).

> google.com cookie while other scripts send unauthenticated requests,
> I’d choose the scoping.

+1e6.  After all, we can improve TLS's protection to bearer tokens, but
we can't really help the web security model much more than that from
here (here == TLS).

Nico
--

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 25 Nov 2014 10:00:50 +0100

> security-model thread :) but we can't really do anything about it from

The TLS WG might define a formal threat model that can be backed up by 
both, on one hand, the cryptographic protocol design, and, on the other 
hand, the security analysis section of the main RFCs that outline 
correct usage in layman's terms. Obviously there SHOULD be a straight 
logical connection between the cryptographic design, the formal threat 
model and the security analysis sections. Otherwise TLS is broken.

Conversely, if TLS WG does this and browsers violate the implementation 
instructions in the security analysis section, the browsers are broken. 
In such a scenario some browser manufacturers and website publishers 
would probably fix the errors at the expense of some interoperability 
issues and some functionality loss, while others would ignore the issues.

The point is, that it is hard to justify that the TLS WG should output 
standards that are not based on a coherent security analysis, just 
because sites like Facebook, Google, EBay, PayPal etc, have a vested 
interest in letting third party web publishers distribute fourth party 
javascript that logs in to their servers with the credentials of the 
client users, and claim this is "secure" just because it is done over 
HTTPS and not in direct conflict with the explicit recommendations of 
the TLS WG.

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 25 Nov 2014 02:15:37 -0800

> TLS library yourself, you have much bigger problems anyway...
I'd explicitly say that the problem is TLS extensions intolerance which would cause browsers to fall back to SSLv3.As a side note, while TLS extensions intolerance is a bit painful too, I feel that it is worth the effort to eliminate. Besides SNI and OCSP stapling, there is also RFC 7366 which is an Encrypt after MAC extension for TLS.
Yuhong Bao

---

From: Hubert Kario <[email-masked]>
Date: Tue, 25 Nov 2014 12:32:01 +0100

On Monday 24 November 2014 21:12:03 Manuel Pégourié-Gonnard wrote:
> > modifications and additions compared to upstream) and as such I don't
> > believe I can send TLS1.0/1.1/1.2 Client Hello without extensions.
> 

to actually detect which ciphers, protocol versions, etc. such server supports 
it would require to write a new tool basically

on the other hand, I can use it as a last resort fallback, just to get a 
number of such servers... I'll try adding that

-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Tue, 25 Nov 2014 14:04:16 +0100 (CET)

> we're talking about recovering multiple bytes.

The 128 on average would apply only to things like an exhaustive key search,
where you do not encounter duplicates, and the worst case would be the
last possibility after 256 tries.

For the poodle attack, you have a random distribution, caused by the IVs
so you will regularly get duplicate wrong guesses during the first 128 tries,
and worst case will be much more than 256 tries.

The math might be what is described here:
http://en.wikipedia.org/wiki/Coupon_collector%27s_problem

Any math/probability takers?

-Martin