Subject: Re: [TLS] An SCSV to stop TLS fallback.

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 3 Dec 2013 18:28:29 -0800

On Thu, Nov 28, 2013 at 4:21 AM, Bodo Moeller <[email-masked]> wrote:
> Everyone,
>
> the new I-D for TLS_FALLBACK_SCSV is now at
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.

Bodo, Adam,

I read your -01 draft while reviewing your OpenSSL and NSS patches for
TLS_FALLBACK_SCSV.

I have some comments.

1. Why don't you also specify a TLS extension, which can be used when
we fall back to a lesser TLS version (but not SSL 3.0)?

I assume specifying only a SCSV is for simplicity.

2. I don't understand why you want the server to report an
inappropriate fallback only if the client drops below the server's
highest supported version.

This means an inappropriate fallback is not always reported to the
client, or it is reported to the client only after multiple fallbacks.

For example, suppose the server supports TLS 1.1 and the client
supports TLS 1.2.

If a middle box blocks only TLS 1.2 ServerHello and injects a TCP
Reset (this middle box behavior was observed, not hypothetical), the
client will retry with a TLS 1.1 ClientHello with the fallback SCSV,
but the server will then finish the handshake successfully.

On the other hand, if a middle box blocks both TLS 1.2 and TLS 1.1
ServerHellos and injects a TCP Reset, the client will retry twice,
first with a TLS 1.1 ClientHello and then with a TLS 1.0 ClientHello.
Although the ClientHellos in both retries have the fallback SCSV, the
server will only respond with an inappropriate_fallback alert to the
second retry.

I think the draft should explain the rationale for this less strict
server behavior.

3. In the Security Considerations section, we have:

   However, it is particularly strongly recommended to send
   TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher
   suites in SSL 3.0 have weaknesses that cannot be addressed by
   implementation workarounds like the remaining weaknesses in later
   (TLS) protocol versions.

It would be nice to name the weaknesses and workarounds explicitly.
The implicit IV weakness of TLS 1.0 and SSL 3.0 can be worked around
by record splitting, so I assume that's not the weakness you're
referring to. Are you referring to the CBC padding timing attacks?

Also, it seems that the main problem with downgrading to SSL 3.0 is
the loss of features and cipher suites that require TLS extensions,
such as Server Name Indication and ECC cipher suites. You already
mentioned that in the Introduction section. If the loss of these
features and cipher suites degrades security, it should be mentioned
in the Security Considerations section as well.

Finally, the fallback to TLS 1.1 loses AEAD ciphers, and the fallback
to TLS 1.0 loses the explicit IV for CBC block ciphers (although the
record splitting workaround is effective). Perhaps these should also
be mentioned.

Wan-Teh Chang

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 4 Dec 2013 10:50:19 +0100

> I assume specifying only a SCSV is for simplicity.

Yes, this is for simplicity and efficiency: we need a SCSV codepoint anyway
for fallback cases that can't use extensions, and if we have that, we'd
gain nothing by sometimes sending a (4-byte) extension instead of a
(2-byte) SCSV.  (Unlike RFC 5746's TLS_EMPTY_RENEGOTIATION_INFO_SCSV, the
new TLS_FALLBACK_SCSV isn't just a special case of a more general
extension, and we also don't require any information back from the server
that would require using the extension mechanism.)

> I think the draft should explain the rationale for this less strict

I'm afraid that I'm not entirely sure I understand what your concern is.

In the second scenario (TLS 1.2 and TLS 1.1 both blocked), the server will
only respond with an inappropriate_fallback alert to the second retry --
but it also wouldn't have a chance to respond to the first retry because it
doesn't see it, due to the middle box aborting that TCP connection.  So no
one would gain anything from sending that alert.

Now let's look at the first scenario (TLS 1.2 blocked by the middle box and
also not supported by the server): in the retry using TLS 1.1, the server
does not send the inappropriate_fallback alert because the client is only
falling back to the TLS version that should have been negotiated anyway: so
this fallback isn't "inappropriate" -- it's annoying from a protocol point
of view (and will typically have a latency impact), but that's just
inherent to the fallback strategy -- the client implements that strategy to
improve interoperability, accepting that protocol overhead.  Whether the
problem for the original connection attempt is caused by the actual
server-side TLS implementation or by something in between should be
irrelevant.

Moreover, if servers were to reject connection attempts with
TLS_FALLBACK_SCSV arriving in their native protocol version, this might
cause a new interoperability nightmare in the future.  Current server
implementations will generally be tested with TLS 1.2 clients, but not
necessarily with clients that send a version number such as 0x03 0x04 (TLS
1.3) or 0x04 0x00 (TLS 2.0?).  They are broken if they don't support that,
but preventing such broken servers from getting rolled out is outside of
the scope of, and not in the power of, this specification.  While I hope
that version intolerance problems can be addressed successfully (thus
rendering TLS_FALLBACK_SCSV irrelevant in practice -- servers will still
need the logic for it, but ideally clients would never actually send it),
that's pretty much orthogonal to this Internet-Draft.  I wouldn't want to
risk arriving at a situation where the server-side logic for
TLS_FALLBACK_SCSV becomes a hindrance for rolling out *new* TLS protocol
versions.

I hope that makes the rationale clearer.  Let me know if it doesn't, though.

Regarding making the draft clearer, I'm considering adding two or three
example cases to the Internet-Draft to discuss how and why
 TLS_FALLBACK_SCSV will allow certain fallbacks and disallow others.

> referring to. Are you referring to the CBC padding timing attacks?

Right, I guess this is a little *too* thin on details.  I wanted to avoid
including a snapshot of currently known problems in currently relevant
ciphersuites, which would only distract from the more generally useful
simple mechanism specified in the Internet-Draft (and seems more suited for
a separate BCP document) -- however, if I choose to touch on particular
problems, I'd better say what those are :-)

The specific problem for CBC ciphersuites in SSL 3.0 is that block padding
is not completely specified.  As of TLS 1.0, three-byte padding (say) will
be of the form 0x02 0x02 0x02, but in SSL 3.0, the first two bytes are
allowed to have any value.  Accordingly, SSL 3.0 (unlike TLS 1.0) does not
require the recipient to validate the padding that it receives.  It has
been known for at least ten years (http://www.openssl.org/~bodo/tls-cbc.txt)
that this results in cryptographic insecurity in the presence of an active
adversary.

Unlike the other CBC ciphersuite weaknesses that have more recently made
the news, this problem is supposedly mostly irrelevant because SSL 3.0 is
way more obsolete than TLS 1.1 -- unless you allow an active attacker to
downgrade your connection to SSL 3.0, that is.  If you actually use SSL
3.0, there is *no* backwards-compatible remedy.  All you can do is prevent
unnecessarily falling back to SSL 3.0 (such as by using TLS_FALLBACK_SCSV).

> in the Security Considerations section as well.

Good point, this clearly is an essential feature less in that particular
downgrade.

> record splitting workaround is effective). Perhaps these should also

I'm not that sure about this one given ongoing discussions about supporting
(at least certain) AEAD ciphersuites before TLS 1.2, and given that (as
discussed above) I want to avoid including a snapshot of current security
problem details, which seems best left for a separate BCP document that can
be updated as needed.  (There are several candidate documents in progress;
see here and wpkops.)

Bodo

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 4 Dec 2013 10:59:23 -0800

Bodo,

Thank you for your reply.

1. Re: a TLS extension vs. a SCSV:

I asked about an extension partly because RFC 5746 uses a dual
extension-SCSV approach, and partly because I wondered if it is useful
for the client to indicate its actual highest supported version in an
extension.

However, I can't come up with a reason why the client's actual highest
version is useful to a server. Although Eric Rescorla and Adam's old
proposals ([1] and [2]) also included the client's actual highest
version (which necessitated multiple, version-specific SCSVs), careful
analysis of their old proposals showed that that version is only
compared with ClientHello.client_version. The boolean result of that
comparison is equivalent to your TLS_FALLBACK_SCSV.

2. Re: the less strict server behavior you specified:

I realized that my example of a client and a server with an
interfering middle box has mistakes. I am sorry that I wasted your
time analyzing an incorrect example.

In spite of my mistake, your reply answered my question, here:

On Wed, Dec 4, 2013 at 1:50 AM, Bodo Moeller <[email-masked]> wrote:
> but preventing such broken servers from getting rolled out is outside of the
> scope of, and not in the power of, this specification.

I don't fully agree with this rationale. The work to implement TLS
version negotiation correctly should be similar to the work to add
support for TLS_FALLBACK_SCSV. Why don't we require that servers that
support TLS_FALLBACK_SCSV must also do version negotiation correctly?
RFC 5746 has such a requirement:

   TLS servers implementing this specification MUST ignore any unknown
   extensions offered by the client and they MUST accept version numbers
   higher than their highest version number and negotiate the highest
   common version.  These two requirements reiterate preexisting
   requirements in RFC 5246 and are merely stated here in the interest
   of forward compatibility.

Do you think it is reasonable for a server to reject a currently
undefined ClientHello.client_version (such as TLS 1.3 or TLS 2.0)? Or
do you think that if something is not tested, it is likely to be
broken? Although I think the latter is true in general, in this
particular case, I think the risk is low. So you are taking a very
conservative approach.

> TLS_FALLBACK_SCSV will allow certain fallbacks and disallow others.

Yes, explaining why you want to allow certain fallbacks would be
helpful, because most people's first thought (as evidenced by my
question and Eric and Adam's old proposals) is to specify a strict
server behavior.

3. Re: the Security Considerations section:

Thank you for explaining what the CBC weaknesses you referred to are.

On second thought, I now suggest that the Security Considerations
section should only consider the security issues of TLS_FALLBACK_SCSV
itself. The section doesn't need to describe the security weaknesses
of SSL 3.0 or older versions of TLS. I agree that would be a
distraction from the simple TLS_FALLBACK_SCSV mechanism specified in
the draft.

4. Why do you not use the server's support of the renegotiation_info
extension as a signal ([3])? Is it because you want to allow servers
to opt in to the fallback prevention mechanism?

Wan-Teh Chang

[1] http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html
[3] http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-02

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 04 Dec 2013 20:12:29 +0100

Hi,

> support TLS_FALLBACK_SCSV must also do version negotiation correctly?

Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is not
servers that don't implement version negotiation correctly, but MITM actively
doing a downgrade attack (and faulty middleboxes, which have the same effect).

Manuel.

---

From: Adam Langley <[email-masked]>
Date: Wed, 4 Dec 2013 14:19:49 -0500

> doing a downgrade attack (and faulty middleboxes, which have the same effect).

I think the chain of sadness goes like this:

1) Some servers don't implement version negotiation correctly, or have
other bugs that happen to be solved by using SSLv3.
2) Therefore some clients implement fallback
3) Therefore attackers can trigger fallback even with correct servers.

The MITM proxies that also had downgrade bugs caused issues with a
Chrome experiment where we removed SSLv3 fallback for Google
properties because it looked, to the client, like an attack. But,
since it's a MITM proxy, it's an attack that the user has authorised.

Cheers

AGL

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 4 Dec 2013 22:05:26 +0100

> comparison is equivalent to your TLS_FALLBACK_SCSV.

Right. This single SCSV is the simplest tool that does the job (and because
it is simple, also easy to get right in implementations).

The work to implement TLS
> RFC 5746 has such a requirement:

All standards-compliant TLS servers are already required to do version
negotiation correctly -- otherwise they wouldn't be standards-compliant TLS
servers :-)  The problem is, something that *appears* to be a
standards-compliant TLS server (and acts exactly like a standards-compliant
TLS server, as far as interactions with current standards-compliant TLS
clients are concerned) may not actually be standards-compliant: current
standards-compliant TLS clients won't ever indicate version TLS 1.3, so
incorrect protocol version negotiation behavior wouldn't be obvious.

Also remember that even if the actual TLS server implementation is
standards-compliant (in particular, version tolerant), a middlebox may
break that, by rejecting ClientHellos with versions that it doesn't
understand.  Such middleboxes clearly are broken, but that alone doesn't
prevent them from getting deployed.

> particular case, I think the risk is low. So you are taking a very

I don't really think that it is *reasonable* for a server (or middlebox) to
reject that, but I wouldn't want to bet the usefulness
of draft-bmoeller-tls-downgrade-scsv-01 on servers (and middleboxes) being
that reasonable.

> to opt in to the fallback prevention mechanism?

[3]
> http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-02
>

I don't want to allow servers to opt in to or opt out of TLS_FALLBACK_SCSV.
 Rather, I want *all* servers to be strict about TLS_FALLBACK_SCSV -- hence
the word "MUST" in the specification of server-side behavior.  This allows
client implementations to send or not send the SCSV based on their security
needs (the draft says that clients SHOULD include
ClientHello.cipher_suites when falling back to a lower protocol version,
where the word "SHOULD" means that "there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed"; RFC 2119).

I don't think that the server's support of the renegotiation_info extension
is necessarily the right signal in practice: for example, if the server
supports it, you might still be deploying a broken version-intolerant
middlebox without anyone noticing that something's wrong.  Maybe, as
described in draft-pettersen-tls-version-rollback-removal-02, such breakage
will eventually become irrelevant in practice, and thus we'll avoid the
need for fallback connections: once we're there, TLS_FALLBACK_SCSV wouldn't
generally be seen on the wire in normal usage (servers would still watch
out for it, but if no client has a need to fall back to earlier protocol
versions, it wouldn't ever be sent).  In this case,
draft-bmoeller-tls-downgrade-scsv-01
won't be doing any harm (it merely requires a small amount of additional
server-side logic).  Well, upon starting to deploy TLS 1.3 or any other
future version, the future us might find out that there *is* then a (new)
need for fallback connections after all, to allow clients to try TLS 1.3 in
the presence of version-intolerant servers and/or middleboxes that, up to
then, didn't appear to be broken.  In that case, the TLS_FALLBACK_SCSV
mechanism will be useful again, until all the version-intolerant servers
and middleboxes have been removed.  Rinse, repeat: with each new protocol
version, TLS_FALLBACK_SCSV may become relevant again until all servers and
middleboxes intolerant to that new protocol version have been evicted from
the internet.

Generally, getting something like TLS_FALLBACK_SCSV deployed on *many*
servers (so that clients can benefit from it at least for many of their
connections) seems more easily feasible than getting rid of (nearly) *all*
broken servers and middleboxes (so that clients can live entirely without
protocol fallback strategies).  So TLS_FALLBACK_SCSV certainly can be
deployed much quicker (if you are interested in keeping some
interoperability with broken servers -- which of course is why protocol
fallbacks are an issue in the first place): To newly roll it out on a
server, you have to make sure that that server (and any middleboxes
handling the traffic to it) support or tolerate the *currently* deployed
TLS versions, which something that you'd automatically be observing in
standard interoperability testing (as long as you use a client supporting
the current TLS version, with TLS_FALLBACK_SCSV for any protocol fallbacks).

As I've said before, you can do both: deploy TLS_FALLBACK_SCSV for best
security even if protocol fallbacks are sometimes necessary; deploy
draft-pettersen-tls-version-rollback-removal-02
to get rid of the need for those fallback connections as soon as we can.
 There's no conflict between these, rather they complement each other --
draft-pettersen-tls-version-rollback-removal-02 doesn't seem right as a
security fix (because (1) you'll have to clean out broken servers and
middleboxes from the internet before you can actually deploy it, and (2)
once we've fixed the internet accordingly, a new TLS version may surface
more breakage), while draft-bmoeller-tls-downgrade-scsv-01 does nothing to
avoid those protocol "downgrades" in which you're only falling back to the
protocol that should have been negotiated anyway.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Wed, 4 Dec 2013 23:05:43 +0000

What percentage of these client fallback operations that actual users browsers are doing in the real world are being triggered for reasons *other* than actual server implementation bugs? I imagine this could be a difficult thing to measure. But I can also imagine the obvious client heuristics (if it fails, try again) could easily be triggered by a busy server or simple packet loss. Couldn't this represent a full 1% of connections, especially now that so many users are on mobile devices?

So if a fallback situation was a slow-loading lousy page experience before, what's it going to be after legitimate servers implement this logic? Will servers actively *refuse* legitimate client's retry connections? If so, isn't this just taking an intermittent slow-failure situation and converting it to an even slower but guaranteed interop failure? If not, what good will downgrade protection logic be?

TLS 1.2 was designed to mitigate some serious potential attacks. BEAST demonstrated these attack vectors could be practical.

We need to recognize ad-hoc client fallback heuristic for what it is: a security vulnerability.

Therefore, clients MUST NOT auto-downgrade.

Therefore, broken servers and middleboxes need to clean up their act or GTFO.

This was always clear to anyone considering it from a protocol security angle. But the strong desire for interoperability and the absence of documented attacks in the 2000's made it hard to argue from principle.

Do we need an RFC a' la 6176 to give security-minded developers an explicit argument from authority?

- Marsh

P.S. I admit to being somewhat skeptical when RFC 6176 was being proposed. But I mentioned it in a meeting the other day and there were literally nods of understanding all around the table. Thanks!

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Wednesday, December 4, 2013 11:20 AM
To: Manuel Pégourié-Gonnard
Cc: [email-masked]
Subject: Re: [TLS] An SCSV to stop TLS fallback.

On Wed, Dec 4, 2013 at 2:12 PM, Manuel Pégourié-Gonnard <[email-masked]> wrote:
> Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is 
> not servers that don't implement version negotiation correctly, but 
> MITM actively doing a downgrade attack (and faulty middleboxes, which have the same effect).

1) Some servers don't implement version negotiation correctly, or have other bugs that happen to be solved by using SSLv3.
2) Therefore some clients implement fallback
3) Therefore attackers can trigger fallback even with correct servers.

The MITM proxies that also had downgrade bugs caused issues with a Chrome experiment where we removed SSLv3 fallback for Google properties because it looked, to the client, like an attack. But, since it's a MITM proxy, it's an attack that the user has authorised.

Cheers

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

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 5 Dec 2013 09:36:28 +1000

Does anyone on the list know of an example website where one can observe a potentially attackable TLS fallback?

Douglas

________________________________________
From: TLS [[email-masked]] On Behalf Of Marsh Ray [[email-masked]]
Sent: December 5, 2013 09:05
To: Adam Langley; Manuel Pégourié-Gonnard
Cc: [email-masked]
Subject: Re: [TLS] An SCSV to stop TLS fallback.

- Marsh

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Wednesday, December 4, 2013 11:20 AM
To: Manuel Pégourié-Gonnard
Cc: [email-masked]
Subject: Re: [TLS] An SCSV to stop TLS fallback.

Cheers

AGL

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 05 Dec 2013 01:33:57 +0100

> a potentially attackable TLS fallback?

You could have a look at https://www.bankofthewest.com ; it is a TLS 1.0  
server that does not tolerate TLS 1.1 or 1.2. Curiously enough, it  
tolerates the version bytes 4.1 and negotiates TLS 1.0

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 05 Dec 2013 01:33:59 +0100

On Thu, 05 Dec 2013 00:05:43 +0100, Marsh Ray <[email-masked]> wrote:

> What percentage of these client fallback operations that actual users  
> browsers are doing in the real world are being triggered for reasons  
> *other* than actual server implementation bugs? I imagine this could be  
> a difficult thing to measure. But I can also imagine the obvious client  
> heuristics (if it fails, try again) could easily be triggered by a busy  
> server or simple packet loss. Couldn't this represent a full 1% of  
> connections, especially now that so many users are on mobile devices?

It is definitely a possibility.

One part of Opera's (v12 and before) logic regarding fallbacks was to fall  
back if the connection took too long to establish after the handshake had  
started, since some problematic servers would never respond if they did  
not like the handshake. IIRC the trigger time was 6 or 10 seconds.

> So if a fallback situation was a slow-loading lousy page experience  
> before, what's it going to be after legitimate servers implement this  
> logic? Will servers actively *refuse* legitimate client's retry  
> connections? If so, isn't this just taking an intermittent slow-failure  
> situation and converting it to an even slower but guaranteed interop  
> failure? If not, what good will downgrade protection logic be?
>
> TLS 1.2 was designed to mitigate some serious potential attacks. BEAST  
> demonstrated these attack vectors could be practical.
>

The main point of contention is how to accomplish this without "breaking  
the web" and how to do this in a fashion that improves security quickly.

The SCSV proposal very likely will not "break the web", but my objection  
is that it will require updates to all the servers, and not just the  
clients, and thus take too long to deploy (case in point: 4 years after  
the Renego problem was discovered, 20% of servers are still not patched).  
Given that. 14 years after TLS 1.0 was released, about 1% of servers still  
only support SSL v3. I do not have high hopes of having SCSVs fully  
deployed in 15 years (unless client vendors decide to, or have to, "break  
the web").

My suggestion have been to update the clients to refuse to use fallback  
when connecting to servers that implement the Renego patch. This have the  
benefit of using a proxy for correct version negotiation, which is already  
deployed on a majority of servers. The drawback of my proposal is that the  
proxy indication is not perfect; there is a small fraction of patched  
servers that are version and/or extension intolerant, and there is a much  
larger fraction of servers that are version intolerant for whatever  
version bytes TLS 1.3+ will use. Some will call the first group as  
"breaking the web", while most will probably agree that the second can  
definitely be called "breaking the web".

The question is, if client vendors agree to "bull through" and refuse to  
fall back, will the server vendors and web site operators fix their  
implementations, and if so, how quickly? The best option in such a  
scenario would probably be a coordinated same-day release  (alternatively  
flipping a flag) of updated clients, particularly browsers, so that web  
sites cannot use the "switch browser" "advice" for fixing the "browser  
bug". (Flipping a flag might be the better option, since this will allow  
the updated browsers to gain a sufficiently large marketshare before  
changing the behavior)

What to do comes down to the answers to a few questions:

  - How much website breakage will be tolerated for a fix? (keep in mind  
that the fix will almost certainly require the client or server to abort a  
connection that cannot be started without a fallback, if not, what's the  
use?)
  - How secure do the vendors, website administrators and users want the  
web to be?
  - How quickly is it desirable to obtain that level of security?

The answers to each of these affect the answer to the others, so the trick  
will be to find a useful compromise that does not compromise security.

-- 
Sincerely,
Yngve N. Pettersen

---

From: James Cloos <[email-masked]>
Date: Wed, 04 Dec 2013 19:52:34 -0500

>>>>> "DS" == Douglas Stebila <[email-masked]> writes:

DS> Does anyone on the list know of an example website where one can
DS> observe a potentially attackable TLS fallback?

I do not know the extent to which it is attackable, but https://archive.org
(aka www.archive.org) only works with ssl/3.0.  TLS-only clients cannot
connect thereto.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 05 Dec 2013 03:15:45 +0100

> (aka www.archive.org) only works with ssl/3.0.  TLS-only clients cannot

This site may be SSL v3.0-only, but it is version and extension tolerant  
up to at least version bytes 3.4, as well as for 4.1. It is also Renego  
patched, and AFAICT support SNI and ECDHE_RSA. Given the latter two, I  
wonder if the server is actually able to support at least TLS 1.0, but  
that it have been disabled somehow, perhaps due to an old configuration  
setting that only specifies SSL v3 as enabled (perhaps in order to disable  
SSL v2).

-- 
Sincerely,
Yngve N. Pettersen

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 05 Dec 2013 09:51:38 +0100

On 05/12/2013 00:05, Marsh Ray wrote:
> connections? If so, isn't this just taking an intermittent
> slow-failure situation and converting it to an even slower but
> guaranteed interop failure? If not, what good will downgrade
> protection logic be?
> 
It seems to me Adam already answered this argument, and his point was that
browsers don't retry plain HTTP connexions anyway, so the situation with
TLS_FALLBACK_SCSV with respect to intermittent failures situations will not be
very different from what it is with HTTP: the browser will show a failure page
and the user will hit the "retry" button.

So, it's not turning an intermittent failure into a permanent one: it's merely
turning an intermittent failure that may not have been visible to the user in
case a silent fallback into an intermittent failure visible to the user.

The only drawback is, as you note, the failure will be slower, compared to what
it would be without any fallback attempt. So the question is, which is worse:
1. Slowing down the display of an error message in case of intermittent failures
with a legitimate and compliant server (the situation with fallback and
TLS_FALLBACK_SCSV), or
2. Being unable to communicate with version-intolerant servers (the situation
without any fallback)?
(I leave out the 3rd option: being vulnerable to MITM downgrades, which I think
we all agree is bad.)

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 5 Dec 2013 12:16:18 +0100

Yngve N. Pettersen <[email-masked]>:

The SCSV proposal very likely will not "break the web", but my objection is
> that it will require updates to all the servers, and not just the clients,
> and thus take too long to deploy (case in point: 4 years after the Renego
> problem was discovered, 20% of servers are still not patched). Given that.
> 14 years after TLS 1.0 was released, about 1% of servers still only support
> SSL v3. I do not have high hopes of having SCSVs fully deployed in 15 years
> (unless client vendors decide to, or have to, "break the web").
>
> larger fraction of servers that are version intolerant for whatever version
> bytes TLS 1.3+ will use. Some will call the first group as "breaking the
> web", while most will probably agree that the second can definitely be
> called "breaking the web".

> implementations, and if so, how quickly? The best option in such a scenario
> would probably be a coordinated same-day release  (alternatively flipping a
> flag) of updated clients, particularly browsers, so that web sites cannot
> use the "switch browser" "advice" for fixing the "browser bug". (Flipping a
> flag might be the better option, since this will allow the updated browsers
> to gain a sufficiently large marketshare before changing the behavior)

As I've mentioned, the two options are not mutually exclusive, so I think
you are constructing a false dichotomy.  We can start to use TLS_FALLBACK_SCSV
ASAP to improve security *ASAP* for connections to *those* servers that do
get updated (80% or even just 10% is better than 0% -- if only the most
important servers that users trust get updated, that's something).  Servers
that aren't version tolerant or extension tolerant will still be just as
broken; having TLS_FALLBACK_SCSV specified doesn't mean that clients are
generally *expected* to fall back, so doesn't affect plans for a fallback
flag flip day or anything like that.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Thu, 5 Dec 2013 19:22:08 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Bodo Moeller
> As I've mentioned, the two options are not mutually exclusive, so I
> think you are constructing a false dichotomy.  We can start to use
> TLS_FALLBACK_SCSV ASAP to improve security *ASAP* for connections to
> *those* servers that do get updated (80% or even just 10% is better
> than 0% -- if only the most important servers that users trust get
> updated, that's something).

It seems to me like there are two scenarios:

Scenario 1.

A vulnerability in *handshake authentication* (stated as before)
is present only in downlevel but mitigated in the highest
protocol version that's common between the legitimate client
and legitimate server.

Thankfully, it's hard to come up with an example for this scenario.
But if it occurs, any protection deployed at the legitimate server
is likely to be rendered useless because the attacker could
impersonate the legitimate server to the legitimate client.
Obviously the attacker would opt not to implement the downgrade
protections in his evil server!

Scenario B.

A vulnerability in *record layer authentication or encryption*
present only in client fallback TLS but mitigated in the highest
protocol version that's common between the legitimate client and
legitimate server.

An example of this scenario is the chosen plaintext attacks on
CBC block padding (e.g., BEAST) that was fixed in 1.1 by sending
an explicit IV. Previous attempts at mitigation had been coded
in OpenSSL years ago for TLS 1.0, but were disabled by default
for compatibility reasons. If an attacker provoked a browser to
fall back to TLS 1.0, he could (in theory) effectively disable
some mitigations in place to prevent this attack.

Protecting against (B) seems like it could be useful, unless it
measurably increases the rate of failed handshakes and delays
in non-attack situations.

http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01#section-3
Server behavior:
> If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
> highest protocol version supported by the server is higher than
> the version indicated in ClientHello.client_version, the server
> MUST respond with a inappropriate_fallback alert.

Say the server implements TLS 1.0 reasonably well, but believes
it supports 1.2. Unfortuantely, it will successfully negotiate
the use of 1.2 but then crashes and hang the socket open until
the client gives up.

RFC 5246 TLS 1.2 says:

http://tools.ietf.org/html/rfc5246#appendix-E
> 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.

and

http://tools.ietf.org/html/rfc5246#section-7.4.1.2
> ClientHello.client_version
>    The version of the TLS protocol by which the client wishes to
>    communicate during this session.  This SHOULD be the latest
>    (highest valued) version supported by the client.

That sounds to me like the client MAY retry with record.version={3,0},
but it SHOULD still send ClientHello.client_version={3,3}.

So for clients that follow RFC 5246 recommendation, what is gained by
sending TLS_FALLBACK_SCSV? Why couldn't we instead recommend that
servers reject with *any* connection attempt for which
ClientHello.client_version < "highest version supported by the server" ?

But draft-bmoeller-tls-downgrade-scsv-01 suggests that clients in the process
of auto-downgrading behave otherwise:

http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01#section-4
Client behavior:
> If a client sends a *ClientHello.client_version* containing a lower
> value than the latest (highest-valued) version supported by the
> client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
> in ClientHello.cipher_suites.

I.e., clients are *lying* about the actual highest version of the
protocol they support and they're doing so against the
SHOULD-level recommendation of the TLS RFC's.

The weakness I see is in draft-bmoeller-tls-downgrade-scsv-01
is that servers are not actually in a position to know the highest
protocol version that the client supports.

Thus a server would have to refuse *any* connection for which the
client sends TLS_FALLBACK_SCSV set. Why? Because the server must
consider the unfortunate possibility that some infernal middlebox
is intolerant to TLS 1.3! (or any future version that the client
may support).

The attacker laughs his ass off as browsers and servers are stuck
in a tangled web of little lies mostly built on good intentions.

Sending a flag to say "oh by the way I'm lying about my highest
version" is not a complete fix.

I only see one correct solution: ripping out this auto-downgrade
logic from clients and putting these broken servers and middleboxes
on notice that they have no place on a secure network.

Only then will environment begin to heal and as it does page load
times would become a bit faster.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 5 Dec 2013 22:43:27 +0100

Marsh Ray <[email-masked]>:

> sending TLS_FALLBACK_SCSV?

In this case, TLS_FALLBACK_SCSV is not sent.  TLS_FALLBACK_SCSV is all
about fallback connections in which the client deviates from the above
recommendation, and sends a lower ClientHello.client_version (i.e.,
pretends that it doesn't actually support the latest protocol).  That's
something that clients actually do, because following the RFC
recommendation doesn't allow them to interoperate with all servers in
practice, unfortunately.

> Why couldn't we instead recommend that

I think you haven't thought that through.  If we did that, it would render
version negotiation pretty much useless: you couldn't ever upgrade servers
to a new protocol version before *all* clients have been upgraded to
support that version.

> client sends TLS_FALLBACK_SCSV set.
>

I don't follow.  Servers would refuse those connections for which the
client (1) sends TLS_FALLBACK_SCSV and (2) doesn't advertise support for
the server's highest supported protocol version.  They don't need to know
the highest protocol version actually supported by the client.

> version" is not a complete fix.

It's obviously not a *complete* fix, but it's a fix that addresses relevant
security problems, *and* can actually be deployed (right now, that is,
without having to fix every broken device on the internet first), *and*
does not get in the way of a complete fix.

> times would become a bit faster.

That's the theoretically correct, non-kludgey solution.  However, the
reality is that client implementers have found it necessary in practice to
implement protocol fallback strategies to improve interoperability (and
users tend to prefer bad latency over unresolvable connection failures; I
fear that trying to explain some game theory on browser error pages
wouldn't help).  In case we manage to evict every server from the internet
that doesn't tolerate TLS 1.2 Client Hello message, that need would go away
for now -- but as soon as we start to deploy TLS 1.3, we might then find
out that new servers are around that work fine with TLS 1.2 but don't
tolerate TLS 1.3 Client Hello messages, and we'd be back to square one.
 There are some things we could try to prevent that, but if this Correct
Solution[TM] doesn't work out, it'll be good to have TLS_FALLBACK_SCSV
around as a backup.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Fri, 6 Dec 2013 19:25:27 +0100 (CET)

Bodo Moeller wrote:
> 
> We can start to use TLS_FALLBACK_SCSV
> important servers that users trust get updated, that's something).

Huh?  Your proposal is not going to improve the security one single bit.

Either the handshake goes through as initially proposed
(no TLS_FALLBACK_SCSV present in ClientHello), and therefore there can
not possibly be any improvement (or any effect).

Or the client's heuristics on network connectivity or handshake failure
from a connection attempt will result in an app-level reconnect fallback
to kick in and a new connection attempt with a more conservative ClientHello
with TLS_FALLBACK_SCSV asserted.  Either that handshake will succeed
as proposed (as if TLS_FALLBACK_SCSV wasn't present), or the handshake
will fail.

So the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
of the TLS protocol not at all, or cause a fatal handshake failure.
And very few, if any at all, of the situations where the handshake fails,
will be instances of an active attack.  And it remains extremely
questionable, when the handshake would succeed, that the attacker
will gain anything at all.

I really do not see any benefit for servers to adopt support for this
interoperability problem.

For this feature to work at all, the prerequisite is that both communication
peers must be updated.  When looking at a protocol feature that requires
both communication peers to be updated as a prerequisite, wouldn't it be
preferable to fix those protocol features of SSL/TLS that we deem necessary
for reliable security to become negotiable even in the "most conservative"
ClientHello that clients are willing to fallback to?  This would make
the TLS handshake immune to "version downgrade" attacks  and allow
programmatic clients to offer TLS features (and cipher suites) that are
artificially and needlessly curtailed to the TLSv1.2 version number right
now to be negotiatiable in conservative ClientHellos.
This would completely obviate the fragile and complex app-level reconnect
fallback logic that is currently necessary to cope with failed TLS
handshakes caused by version-intolerant servers and dense middle boxes.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Fri, 6 Dec 2013 13:33:04 -0500

On Fri, Dec 6, 2013 at 1:25 PM, Martin Rex <[email-masked]> wrote:
> ClientHello that clients are willing to fallback to?

Fallback behaviour is needed for wide variety of buggy servers,
including those that are intolerant to unknown extensions.

I don't believe that there's a ClientHello format that is both devoid
of compat issues and sufficiently expressive to be able to negotiate
what we need now and in the future.

Cheers

AGL

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 06 Dec 2013 13:45:31 -0500

On 12/06/2013 01:25 PM, Martin Rex wrote:
> will be instances of an active attack.

This is probably also true of X.509 certificate validation failure as
well, since there are more self-signed or expired certificates in active
use than there are active MITM attackers.  Are you suggesting that TLS
would be better off not checking certificate validity?

> And it remains extremely

What the attacker can gain presumably depends on what features the
client is willing to sacrifice during fallback.  Presumably, the client
gives up specific features of the newer versions: e.g. AEAD, when
falling back below TLS 1.2, or possibly all TLS extensions for fallback
all the way to SSLv3 (to accomodate old extension-intolerant SSLv3 servers).

It looks like you're saying that none of these more modern features are
useful tools in defending against an active attacker.  Do you really
think that?

	--dkg

---

From: Brian Smith <[email-masked]>
Date: Fri, 6 Dec 2013 14:22:29 -0800

On Wed, Nov 27, 2013 at 7:28 AM, Adam Langley <[email-masked]> wrote:
> On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith <[email-masked]> wrote:
>> these fallback connections add a lot of
>> latency. If we attempt a fallback connection in response to a
>> connection reset, and we receive an inappropriate_fallback alert, then
>> we'd have to make yet *another* connection without the fallback.
>
> I didn't have that in mind. In the code as I currently have it
> written, an inappropriate_fallback doesn't trigger an "upgrade".
> Rather the original error code that triggered the downgrade is
> remembered and returned.
>
> So the connection might go: TLS 1.2, connection reset; fallback to TLS
> 1.1, inappropriate_fallback; fail the connection with a connection
> reset error.
>
> We don't retry HTTP connections, after all.

Sorry for the delay.

Firefox does retry for connection resets. In fact, our TLS intolerance
mechanism is implemented by converting the error that causes us to
suspect TLS intolerance into a connection reset error code, and then
returning that connection reset error to our HTTP stack. In the case
of a RST in the middle of a GET request when pipelining is enabled,
Firefox will even resend the GET request on the assumption that it is
idempotent. Firefox has done things this way for a very long time,
presumably to help users get the results they want when they are on
flaky networks.

Anyway, it seems bad get a positive "yes, you can reach me and I will
respond" response from the server and then stop trying to communicate
with it. It is better to find some way to get the HTTP response that
the user is waiting for, if we can find one.

This is why I think it is better to try backporting TLS-1.2-only
cipher suites to TLS 1.1 and TLS 1.0, and then have clients send all
the same extensions in TLS 1.0 and TLS 1.1 that they would send in TLS
1.2, plus an indication of the max version supported in an extension
or an SCSV, and then let the server "upgrade" the connection to TLS
1.2 by using TLS 1.2 features while still indicating in its
ServerHello.server_version.

Granted, there is significant compatibility risk in doing this,
because some intermediary may choke somehow.  It will require
widespread experimentation to see how well it works. I am happy to
change Firefox to support this experiment if we can find partners
running servers on the internet that are also willing to experiment
with it.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Fri, 6 Dec 2013 22:31:00 +0000

Hi,

the draft only concerns HTTPS (no other client side implementation attempts
a reconnect when it receives
a RST on  TLS 1.x [which is bad to start with but apparently necessary]).

A solution that solves some of the mentioned problems without any protocol
change is
to pin the TLS version the same way as certificates are pinned. And while
pinning the TLS
version it should also be considered to pin the cipher suite ("Use this
cipher suite or
a better one").

After first connect the client will not allow any lesser security (TLS 1.3,
ECDHE, ..) than the one
used on last connect.

regards,

ralf

On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith <[email-masked]> wrote:

> On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <[email-masked]> wrote:
> >   In the event that a client is making a fallback connection, it
> > includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> > current server which sees this cipher suite in a ClientHello SHOULD
> > return a fatal alert, inappropriate_fallback (86) and abort the
> > connection.
>
> Adam, I think what you propose makes sense. However, I think it might
> not be ideal if there are any circumstances where the browser could
> accidentally fall back to a lower version--e.g. falling back after a
> timeout or falling back in response to the connection being reset.
> AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
> from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
> be some false positives here. In addition to potentially reducing the
> security of the connection, these fallback connections add a lot of
> we'd have to make yet *another* connection without the fallback. All
> other things being equal, it would be better if the server could
> respond respond exactly as it would with a TLS 1.2 ClientHello,
> without downgrading the cipher suite or any other feature, more like
> what Martin Rex suggested.
>
> However, I don't think it is realistic to backport features all the
> way to SSL 3.0. The information in the TLS extensions is too
> important, and trying to define good defaults for missing extensions
> that make sense long-term seems like it will just bind our hands too
> much in the future.
>
> So, we should could consider backporting TLS 1.2 cipher suites to TLS
> 1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
> for for SSL 3.0 handshakes only.
>
> Whether this complication is justified depends on how frequently we
> receive false-positive connection resets (and anything else that can
> be a false positive) and how much we care about optimizing performance
> for that case.
>
> Cheers,
> Brian
> --

---

From: [email-masked] (Martin Rex)
Date: Sat, 7 Dec 2013 05:22:32 +0100 (CET)

> would be better off not checking certificate validity?

When both peers manage to signal to each other that they could
have done better, why moaning, failing and annoying the user,
when those peers could simply *USE* those better features instead.

> useful tools in defending against an active attacker.  Do you really

I really think that trying to reduce the large scale of grey into
a binary black/white guess by the server about what the client
_might_ deem appropriate is doomed to fail.

If the client wants to make a conscious security trade-off decision
about what features it is willing to sacrifice to obtain interoperability,
then it is the _client_ which should perform the decision.  And in case
of a client operated by a human user (such as a web browser), that
trade-off might involve asking the user.

The server doesn't know anything about the client's motivation,
nothing about the actual request that the client is intending to
submit and nothing about the trade-off that the client would
be willing to perform (rather than fail).

Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
thing the client might be "loosing" is a little performance, and
that AEAD can not currently be negotiated and used unless
ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
of the specification(s) that could be easily fixed.

Btw. am I reading this page correctly:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx

Does Microsoft limit AES-GCM really to ECDHE_ECDSA on Win7 and Win8
i.e. unavailable with ECDHE_RSA ?

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 7 Dec 2013 05:38:43 +0100 (CET)

Adam Langley wrote:
> Martin Rex <[email-masked]> wrote:
>>

If you *NEED* a certain feature, then there would not be a point in
a reconnect fallback to a ClientHello that doesn't have that feature.
So you would not need an SCSV to cover this, methinks.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Fri, 6 Dec 2013 22:32:52 -0800

To clarify.
> of the specification(s) that could be easily fixed.
I am assuming you are discussing the modes as specified and
implemented in TLS? In that case you are dead wrong.
Lucky 13, BEAST, and even if we drop all that no protocol depending
both on SHA1 and AES can be stronger than one depending
on AES alone.
Sincerely,
Watson Ladd

---

From: [email-masked] (Martin Rex)
Date: Sat, 7 Dec 2013 07:42:54 +0100 (CET)

Watson Ladd wrote:
[ Charset UTF-8 unsupported, converting... ]
> both on SHA1 and AES can be stronger than one depending

Lucky 13 and BEAST are completely irrelevant for the majority
of usage scenarios, and there's even a simple 1/(n-1) record splitting
workaround for BEAST for those with paranoia.

I don't know what you mean by "AES alone", but if you are refering
to "AES-GCM", that isn't AES alone, but AES in combination with GHASH,
and HMAC-SHA1 beats the security of GHASH by a huge safety margin.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Fri, 6 Dec 2013 22:50:32 -0800

> workaround for BEAST for those with paranoia.
Paranoia is a requirement for this WG.
> and HMAC-SHA1 beats the security of GHASH by a huge safety margin.
No, GHASH has an unconditional security guarantee, while HMAC is only
conjectured to be secure.
If you break AES-GCM you break AES, and hence AES-CBC-SHA1.
AES-CBC-SHA1 also falls if
HMAC fails.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: [email-masked] (Martin Rex)
Date: Sat, 7 Dec 2013 08:32:25 +0100 (CET)

> Paranoia is a requirement for this WG.

TLSv1.1 and TLSv1.2 seem to have been developed without paranoia.

The attack surface provided by mac-pad-encrypt rather than the
obvious fix pad-mac-encrypt, which Lucky 13 exploited, was clearly
pointed out by Serge Vaudenay in 2001, but completely ignored by
the TLS WG in 2006 (TLSv1.1) and again in 2008 (TLSv1.2).

Replacing the (rsa,md5+sha1) digitally-signed from SSLv3->TLSv1.1 with
(rsa,sha1) or (rsa,md5) in TLSv1.2 is huge degradation in security,
certainly nothing that someone with paranoia would do. 

> conjectured to be secure.

If that were a real concern, then you would have to violently
oppose to Peter's (and other folks) suggestion to change
from mac-pad-encrypt to pad-encrypt-mac (aka EtA).

> AES-CBC-SHA1 also falls if

Currently HMAC-SHA1 in TLS is protected by AES CBC encryption,
so it is simply impossible to attack HMAC-SHA1 without first breaking AES.

In contrast to AES-GCM, you can not target and flip individual bits
of the MAC'ed plaintext from AES-CBC-SHA1 nor can you target and flip
individual bits from the HMAC-SHA1 output.  You actually do not not
anything about what goes in and what comes out of HMAC-SHA1 right now.

-Martin

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 07 Dec 2013 12:40:50 +0200

Hi Ralf,

I like the idea of pinning the version number, but I don't think it will 
work well in clusters without significant tinkering (i.e., protocol 
changes): the client connects to cluster member A which has just 
upgraded to TLS 1.3 and immediately pins that server to 1.3. Now it 
connects to another cluster member which is still on TLS 1.2, and the 
connection is reset.

I don't understand how you could pin "ECDHE" - you would need to define 
whether DHE is better or worse than ECDHE, and I don't think we want to 
make that judgment call.

Thanks,
	Yaron

On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:
> Hi,
>
> the draft only concerns HTTPS (no other client side implementation
> attempts a reconnect when it receives
> A solution that solves some of the mentioned problems without any
> protocol change is
> to pin the TLS version the same way as certificates are pinned. And
> while pinning the TLS
> After first connect the client will not allow any lesser security (TLS
> 1.3, ECDHE, ..) than the one
> used on last connect.
>
> regards,
>
> ralf
>
>
> On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sat, 7 Dec 2013 14:05:41 +0000

Hi Yaron,

TLS Version Pinning:
I do not have a solution for the cluster situation but I assume that the
same problem exists for pinning of the certificate. It should be solved the
same way.

I think this would solve the fallback issue in an elegant way with a
feature that is anyway already coming to the browsers and without protocol
modifications.

CIPHER-SUITE Pinning:
We are already making the judgment call which ciphers are NULL, WEAK and
STRONG. If I use 'STRONG' on my first connect I would not like to be
downgraded to WEAK even that in general I would like to have weak enabled
in my browser for other websites.

regards,

ralf

On Sat, Dec 7, 2013 at 10:40 AM, Yaron Sheffer <[email-masked]>wrote:

> changes): the client connects to cluster member A which has just upgraded
> to TLS 1.3 and immediately pins that server to 1.3. Now it connects to
> another cluster member which is still on TLS 1.2, and the connection is
> reset.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 07 Dec 2013 17:02:32 +0200

Hi Ralf,

No, AFAIU the problem does not exist for cert pinning, because there is 
protocol involved. Specifically, the server sends out HTTP headers to 
indicate the pinning and its lifetime. So (for example) you can start by 
changing the certs on all cluster members and only afterwards enable 
pinning on all of them.

Re: cipher-suites, if I'm using ECDHE it doesn't mean that I want future 
DHE connections to fail. It is absolutely legitimate to change t
setting he server's software for some reason, and to thereby also change 
the list of supported ciphersuites. I don't think we can ever reach 
consensus on weak vs. strong cipher-suites on this mailing list, and 
such consensus would be needed to standardize such a solution.

Thanks,
	Yaron

On 12/07/2013 04:05 PM, Ralf Skyper Kaiser wrote:
> same problem exists for pinning of the certificate. It should be solved
> the same way.
>
> feature that is anyway already coming to the browsers and without
> protocol modifications.
>
> CIPHER-SUITE Pinning:
> downgraded to WEAK even that in general I would like to have weak
> enabled in my browser for other websites.
>
>
> regards,
>
> ralf
>
>
>
> On Sat, Dec 7, 2013 at 10:40 AM, Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Ralf,
>
>     I like the idea of pinning the version number, but I don't think it
>     will work well in clusters without significant tinkering (i.e.,
>     protocol changes): the client connects to cluster member A which has
>     just upgraded to TLS 1.3 and immediately pins that server to 1.3.
>     Now it connects to another cluster member which is still on TLS 1.2,
>     and the connection is reset.
>
>     I don't understand how you could pin "ECDHE" - you would need to
>     define whether DHE is better or worse than ECDHE, and I don't think
>     we want to make that judgment call.
>
>     Thanks,
>              Yaron
>
>
>         On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>              _________________________________________________
>              TLS mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>
>
>
>
>
>
>         _________________________________________________
>         TLS mailing list
>         https://www.ietf.org/mailman/__listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>
>
>     _________________________________________________
>     TLS mailing list
>     https://www.ietf.org/mailman/__listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sat, 7 Dec 2013 15:14:15 +0000

Hi

> changing the certs on all cluster members and only afterwards enable

This feature could be optional and a server admin could decide to use this
feature (e.g. to advertise TLS Version pinning and CIpher-suite pinning).

A server-cluster can opt-out to use the feature.

I'm not yet giving up hope to also find a solution that makes this feature
available to server-clusters. It could be a technical solution or a
management/process solution.

> consensus on weak vs. strong cipher-suites on this mailing list, and such
> consensus would be needed to standardize such a solution.
>

Sadly can we not make up our mind which ciphers are strong or weak and we
always shift this responsibility to the server-admin. We have done so in
the past and solving this now would be out-of-scope for the proposed
TLS-version/Cipher-suite pinning discussion.

regards,

ralf

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 07 Dec 2013 16:33:36 +0100

Hi,

> changing the certs on all cluster members and only afterwards enable 
Maybe I'm missing something obvious, but it seems to me the problem with version
pinning could be solved by explicitly stating the minimum TLS version in the
HTTP headers, then. That way, cluster admins could upgrade some servers to say
1.3 while keeping the pinning on 1.2, and then update the pinning to 1.3 only
when all the servers in the cluster are upgraded to 1.3.

Manuel.

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sat, 7 Dec 2013 17:01:40 +0000

Hi,

goo idea.

Another idea is to disable TLS-version pinning on the all servers until all
servers are upgraded to 1.3 and
 then enable TLS version pinning again.

Lets assume the client has TLS 1.2 pinned and the admin wants to upgrade to
TLS 1.3.

While pinning is disabled (short period of time) all clients who have
already pinned the TLS 1.2 will connect to TLS 1.3 put not pin TLS 1.3.
This way the clients can connect to other servers in the cluster that are
still running on TLS 1.2. Once all servers have been upgraded the admin can
turn on pinning again and on next connect the client will update the min.
allowed TLS version to 1.3 (or whatever the highest supported version by
the client is).

regards,

ralf

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 9 Dec 2013 14:53:11 +0100

> Huh?  Your proposal is not going to improve the security one single bit.

[....] the use of the TLS_FALLBACK_SCSV will either *NOT* affect the rest
> will gain anything at all.

To be entirely clear, there's obviously no security improvement from
TLS_FALLBACK_SCSV for clients that never use fallback connections, and for
servers that only have clients without such fallback strategies.

The older protocol versions have some very real security problems.  I don't
think it's relevant that, as far as we know, these security problems are
not currently routinely exploited by attackers.

> ClientHello that clients are willing to fallback to?

Deploying TLS_FALLBACK_SCSV on even just a single server is sufficient to
protect connections to that server.  Clients can use it without having to
wait for all servers to be updated.

If we can also get all servers fixed so that there's no longer a need for
potentially insecure fallback connections, all the better, but it's
certainly going to take longer before clients can be updated to benefit
from that kind of change.  The TLS_FALLBACK_SCSV specification does not
prevent any such effort -- we don't have to choose between *either*
deploying TLS_FALLBACK_SCSV *or* fixing the protocol properly.  (The
TLS_FALLBACK_SCSV Internet-Draft is intentionally agnostic about what a
proper fix would look like.  Once we manage to fix the protocol, clients
would simply stop to send TLS_FALLBACK_SCSV, while servers would continue
to watch for it.)

So I don't agree with the word "preferable": it suggests that the options
are mutually exclusive, when in fact they are not.

Bodo