Subject: [TLS] Minutes from Tuesday

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Oct 2014 10:44:24 -0400

Here's the draft minutes for today's interim.  Please post corrections to the list.

Should we remove SSLv3 from the session hash draft?  Various points about why SSLv3 is either not being used, or in devices that aren't being updated. One more update to remove SSLv3, some other cleanups, and then go to WG LC. Sean will try to force out any issues for discussion in Hawaii.

Bodo slides are at https://github.com/tlswg/wg-materials/blob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf   Based on list feedback, going to add some clarifications (no changes to the mechanism).  False start I-D needs to be updated since attacker can force a version; Bodo to do that. Discussion of distinguishing between TCP reset (in FF) and version intolerance. Discussion of when to 'guess' failure is transient or version intolerance. Need to add some guidance to the I-D: mixing SCSV and version-intolerant servers will cause a pain. Sean went through issues raised on mailing list.

What is status of false-start? Was held back by Google for interop concerns. MSFT always tries based on cipher-suite (says MT); others do it conditional on NPN or ALPN and a modern cipher like a DH. It's in wide use. Bodo will update the draft and ask the WG to adopt

Dkg on named groups. No longer an extension; allocating points within the namedcurve list, they are finite-field groups. Interacts with cipher-suite list.  Discussion about adding ordering semantics between the two lists. Change: clients that wish to express an ordering may order the curves/groups in their order of preference.

Discussion of RC4 draft.  Andrei via phone. Room strongly supports prohibiting RC4. Discussion about being able to address concerns raised by a few. Chair will close discussion and move it forward. Sean to include text about "just upgrade to TLS 1.2" as we considered alternatives and rejected them in his shepard notes or equivalent. Mention that youtube encodes video streams using RC4 only.

Return to DH named groups.  Dkg prefers not-using IKEv2 primes, so that national-scale adversaries workload doubles. We'll ask CFRG "do you have a problem with these groups?" Decided that SRP re-use of IKEv2 groups is not an issue. Discussion of sizes.  Sean going to straw poll the list for 2048 or 2432, will work with dkg to draft the message. Proposed sizes 20xx 3032 4096 8192. Discussion of having server return the full key.  Dkg to come back to the mailing list. Discussion of how to do PSK with PFS; neat hack/thought, treat it like a resumption.

Compressed points. Certicom says no IPR coverage any more. Likely to drop uncompressed points (and their negotiation) from TLS 1.3  ekr to do a straw poll on the mailing list.

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

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 Oct 2014 17:05:36 +0200 (CEST)

> Bodo slides are at https://github.com/tlswg/wg-materials/blob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf   Based on list feedback, going to add some clarifications (no…

The current fallback-scsv is embarrassing.

Rather than aborthing the TLS handshake, the server ought to include
a TLS extension in the ServerHello indicating that he recognized a
potentially inappropriate fallback and otherwise continue the TLS handshake
in the regular fashion, leaving the decision of whether&how to continue
entirely up to those clients who do perform insecure fallbacks.

This would also allow clients (browsers probably) to gather real data
on potentially incorrect fallbacks, rather than have users face random
connection failures.  Connection failures for singular object may
appear easy to identify, but if it affects only small objects within
complex pages, the underlying cause of problems may be hard to identify.

And it would then be a decision of the (fallback-performing) clients
whether and when to start hard-failing, once they've sorted out their
connection management and figured out how to deal with false positives
in their fallback heuristics.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Oct 2014 18:19:51 +0200

> entirely up to those clients who do perform insecure fallbacks.

That would work too, but the server would then be doing all the work to
send a ServerKeyExchange even if the client is going to abort the
connection.

> on potentially incorrect fallbacks, [...]

> in their fallback heuristics.

Well, even just having to fall back to make the connection work indicates
that something is wrong -- that's not a generally expected way of
establishing a TLS connection. (Clients can gather some statistics without
sending TLS_FALLBACK_SCSV if they want to use the connection regardless.)
It seems that the response mechanism that you propose would allow the
server to confirm to that client that the server noticed that the client
noticed that something is wrong. What would really be gained by that,
compared to what the current TLS_FALLBACK_SCSV protocol offers?

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Oct 2014 18:41:42 +0200

Salz, Rich <[email-masked]>:

Here’s the draft minutes for today’s interim.  Please post corrections to
> the list.

> Discussion of RC4 draft.  Andrei via phone. Room strongly supports
> prohibiting RC4. Discussion about being able to address concerns raised by
> a few. Chair will close discussion and move it forward. Sean to include
> text about “just upgrade to TLS 1.2” as we considered alternatives and
> rejected them in his shepard notes or equivalent. Mention that youtube
> encodes video streams using RC4 only.
>

That's not right: YouTube video streams currently can use two cipher
suites, TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The
interoperability problem mentioned in the meeting was that
TLS_RSA_WITH_AES_128_GCM_SHA256 (without ECDHE) isn't a supported cipher
suite in Firefox, and RC4 is RC4;
https://bugzilla.mozilla.org/show_bug.cgi?id=1029179.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 22 Oct 2014 00:34:22 +0200

Salz, Rich <[email-masked]>:

> Bodo slides are at
> https://github.com/tlswg/wg-materials/blob/master/20141021_interim/TLS_FALLBACK_SCSV_IETF_TLS_Interim_Oct_2014.pdf
>

More official link:
http://www.ietf.org/proceedings/interim/2014/10/21/tls/slides/slides-interim-2014-tls-3-1.pdf

---

From: Marsh Ray <[email-masked]>
Date: Wed, 22 Oct 2014 01:09:27 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Tuesday, October 21, 2014 8:06 AM
> Rather than aborthing the TLS handshake, the server ought to 
> include a TLS extension in the ServerHello indicating that he 
> recognized a potentially inappropriate fallback

Even better would be something the client could authenticate,
but that an attacker might not be able to detect without a
full real-time compromise of the master secret. E.g.,
invert all the bits in the Finished message.

> and otherwise 
> continue the TLS handshake in the regular fashion
> clients who do perform insecure fallbacks.
>
> This would also allow clients (browsers probably) to gather 
> real data on potentially incorrect fallbacks, rather than 
> have users face random connection failures.

If the client was really determined to use a downgraded connection,
it could always just connect again without FALLBACK_SCSV.

But that would be stupid.

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Tue, 21 Oct 2014 18:35:41 -0700

On Tue, Oct 21, 2014 at 9:41 AM, Bodo Moeller <[email-masked]> wrote:
> That's not right: YouTube video streams currently can use two cipher suites,
> TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The

(And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's
already enabled in some locations.)

Cheers

AGL

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Oct 2014 22:32:55 -0400

> The current fallback-scsv is embarrassing.

You seem to be the only one who thinks this.

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

---

From: Florian Weimer <[email-masked]>
Date: Wed, 22 Oct 2014 11:15:33 +0200

> You seem to be the only one who thinks this.

I agree with Martin, but I'm not sure yet for whom I consider it
embarrassing.

---

From: [email-masked] (Martin Rex)
Date: Mon, 27 Oct 2014 20:38:31 +0100 (CET)

> send a ServerKeyExchange even if the client is going to abort the

I do believe the server load issue here to be sufficiently close to
marginal to be irrelevant.

> sending TLS_FALLBACK_SCSV if they want to use the connection regardless.)

The problem with having the server (rather than the falling-back client)
abort the connection is that the client has no reliable indicator to
figure out the reason for connection failures,  and have to continue
relying on flawed heuristics.  MSIE has a similar bug in connection
management that FF used to have over several years (and which could often
be observed/reproduced by by hitting <F5> ("reload") quickly several
times on complex pages).  On MSIE, I saw it as a result of complex
pages with Javascript-based navigation that performed (and killed)
background downloading of images.

> compared to what the current TLS_FALLBACK_SCSV protocol offers?

It would leave the decision whether to abort or continue the handshake
with the one-and-only connection peer that is (a) doing the fallback
and (b) in the position to establish another connection and attempt
another handshake, and (c) query the user interactively if something
odd is going on.

I would gladly add a server extension into ServerHello of our TLS
implementation in response to a FALLBACK SCSV, whereas I will entirely
ignore this proposal as is.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Oct 2014 12:10:35 +0100

> marginal to be irrelevant.

Normally, yes (after all, TLS_FALLBACK_SCSV isn't expected to be seen *at
all* as long as everything works well). The kind of scenario I'm thinking
of is one with clients on bad wireless networks, which can lead to rather
frequent spurious handshake failures followed by (inappropriate) fallback
retries.  I just don't think that the additional benefit (per connection)
is worth the additional computational effort (per connection), and the
extra latency: for many clients, there is *no* additional benefit at all.

I'm also concerned about the mechanism being more error-prone if servers
don't respond with a fatal alert.  If it's a warning alert (or other
signal) instead, clients will require additional code to handle this
properly, whereas reacting to a fatal alert is something that all TLS
implementations already know how to do.

We could create a client-side signal that allows the client to specify the
desired AlertLevel, but this again would add further complexity to the
protocol (by making server behavior more complex).

> figure out the reason for connection failures,

You have the fatal alert telling you that the current protocol version with
TLS_FALLBACK_SCSV wasn't right.

> another handshake, and (c) query the user interactively if something

You can basically do the same thing with the TLS_FALLBACK_SCSV mechanism,
it just may require an additional connection.

Fallback retries always *are* a kludge, hence I want to keep the
TLS_FALLBACK_SCSV mechanism very simple and easy to support rather than
optimizing for special scenarios.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Fri, 31 Oct 2014 02:26:22 +0100 (CET)

Bodo Moeller wrote:
> I just don't think that the additional benefit (per connection)

There is a *HUGE* benefit for clients.  They will be able to properly
recognize accidental fallbacks that should not have happened in the
first place.  Otherwise it takes bug reports and several years before
client connection management failures get fixed.

> signal) instead

NO Alert at all.  Regular continuation of the handshake.

>
> clients will require additional code to handle this properly,
> whereas reacting to a fatal alert is something that all TLS

That reaction is called interop failure.  That is the far opposite
of what IETF working groups are supposed to consciously cause to happen
when the alternative would be to make interop succeed.

As I keep saying, the server decides based on the server's policy
whether it is OK to proceed with the handshake and pick his favorite
properties from the parameters proposed by the Client, and then it is
up to the client to determine, based on the client's own policy,
whether the client is OK to continue.

The TLS protocol offers a negotiation of protocol parameters, and it
actually cryptographically protects this negotiation.  It is silly for
a client to propose parameters that it actually does not want to
have negotiated.  

> protocol (by making server behavior more complex).

The Server ought to continue the regular TLS handshake SUCCESSFULLY.
But it could include a ServerHelloExtension in response that tells
the client "if you really think you could do better, and your app
on top contains the megabyte of flawed "downgrade dance" app coding
that makes Poodle so successful, then you may want to reconsider
your ClientHello offer."

Even when falling back all the way to SSL VERSION 2.0 CLIENT-HELLO,
should be safe and spec-compliant for the client to offer
at least { 0x03, 0x01 } aka TLSv1.0 and the mandatory-to-implement
TLSv1.2 cipher suite TLS_RSA_WITH_AES_128_CBC_SHA

   https://tools.ietf.org/html/rfc5246#section-9

and I really do not understand why all those downgrade dancers
didn't fix their code at least when they renego-patched, because
back then we discussed rather extensively how bad it would be if
an attacker would be able to remove a capability from ClientHello
that both client and server support, and the client even believes
to be a necessity.

-Martin