Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

From: Peter Gutmann <[email-masked]>
Date: Wed, 25 Sep 2013 10:30:12 +0000

Eric Rescorla <[email-masked]> writes:

>Do you think you could address the questions I asked below?

Sorry, given the email avalanche recently and the fact that I wasn't sure what
the questions were getting at, I'd put them in the TODO list.

> - Because this draft relies on extensions, it seems not to resist
>   active attack when clients do insecure version fallback
>   (see for instance:
> http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)

Right, but given that the problem is broken clients I'm not sure what the
issue is.  Anything that falls back to older, less secure versions of
protocols is going to be vulnerable to things that the newer protocols fix.

> - Maybe I am misreading the draft, but I'm unclear on how you get
>    the TLSCompressed.length for the MAC computation in Section 3.
>    Does this have the same issue as was raised for McGrew's CBC AEAD
>    draft?

What was the issue raised for the AEAD draft?  Since I'm not sure what the
question is asking, the only real response I can give is that there's a number
of implementations out there that interoperated without problems, so whatever
the perceived problem is, it doesn't seem to be much of an issue.

Peter.

---

From: Alfredo Pironti <[email-masked]>
Date: Wed, 25 Sep 2013 13:01:36 +0200

> the perceived problem is, it doesn't seem to be much of an issue.

The issue is on the receiving side, about computing the
"TLSCompressed.length" field that you need to put in your local
computation of the MAC. I believe
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
as currently defined suffers the same issue.

On receiving side, currently you can't just take the ciphertext and
additional data and locally derive a MAC from it, because the MAC
contains the TLSCompressed.length field, which is the lenght of the
plaintext *before* padding. So, currently, you need to:
1) decrypt
2) split plaintext from pad to recover the TLSCompressed.length value !!!
3) check the MAC

note that step 2 is performing an operation on sensitive data *before*
the MAC has been checked, which actually exposes a very similar
padding oracle to the one that affects current MtPtE.

Fix is however not too difficult: in the MAC, include the whole
"plaintext+padding" length, so that it can be computed directly form
the ciphertext length, without need to decrypt it first.

As a note, this details are already sorted out in
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02
where the whole padded length is included in the MAC, and an
"implementation note" paragraph forces the implementer to perform
decryption steps in the right way, avoiding "smart" developers to take
insecure shortcuts.

Best,
Alfredo

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

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Sep 2013 13:03:18 +0200

> protocols is going to be vulnerable to things that the newer protocols fix.

Consider a client and server that both support a secure protocol version,
but where the client will reconnect using an older protocol version if it
suspects that that's necessary for interoperability.  Since in this
scenario, the client won't reliably know if handshake failures indicate
interoperability problems with the actual server or with an active
attacker, having a security fix that can be applied to the older protocol
version as well has a clear benefit.

(Also, offering this Encrypt-then-MAC option rather than just switching to
AEAD ciphersuites completely could make it easier to fix older
implementations before they can migrate to newer protocol versions; but I'm
very skeptical about this rationale in the case of falling back to SSL 3.0
[and no TLS extensions] -- if an implementation really is stuck at SSL 3.0,
that looks hopeless to me.)

While removing SSL 3.0 support entirely would avoid this kind of problem,
SSL 3.0 is still sometimes required for interoperability. (Cf. the history
of RFC 6187: http://tools.ietf.org/html/rfc6176)

So maybe the right fix to this kind of problem is to adapt an idea from
draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
that would *only* be used in SSL 3.0 connections by clients that have
downgraded, and tells the server "If you can read this, tear down the
connection because we shouldn't actually be using SSL 3.0 for this
connection"?

Bodo

---

From: Ralph Holz <[email-masked]>
Date: Wed, 25 Sep 2013 13:30:34 +0200

Hi,

> While removing SSL 3.0 support entirely would avoid this kind of
> problem, SSL 3.0 is still sometimes required for interoperability. (Cf.
> the history of RFC 6187: http://tools.ietf.org/html/rfc6176)

We have some empirical data, albeit only for servers. In our most recent
IPv4-wide scan, only 3% of servers required us to downgrade to SSL 3 in
order to complete the handshake. All others were OK with TLS1.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Adam Langley <[email-masked]>
Date: Wed, 25 Sep 2013 09:11:38 -0400

> connection because we shouldn't actually be using SSL 3.0 for this

(I think I would want such an SCSV to indicate TLS 1.2 support rather
than TLS 1.0 support, but that's just a detail.)

A possible problem with this approach is that there are both broken
servers and broken networks and I don't have good information about
the latter. (It's obviously much more difficult to detect.)

Broken networks can stop the transit of TLS based on version and that
has been observed, very rarely, in the wild. However, just because we
haven't observed it much doesn't mean that it's not happening, it just
means that we rarely get to observe it.

If it turns out that broken networks are insignificant then we can use
an SCSV to prevent version downgrade. (Using the renegotiation
extension for this would have been nice, but I think we've already
lost that battle.)

However, if they are not then we may need to run modern ciphersuites
in older versions.

The first step to figuring this out is that Chrome will stop
downgrading to SSLv3 when talking to Google servers soon. If that
works, and we're able to get to the point where we can remove fallback
completely without breaking networks, then that will answer the
question.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Sep 2013 15:21:25 +0200

> means that we rarely get to observe it.

I know -- and the boundaries between "broken network" and "attacker" may
not always be clear: if the broken network effectively *is* an attacker
(even unintentionally so) and weakens the cryptography of the connection,
it may make a lot of sense to avoid that network entirely.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Sep 2013 09:38:53 -0700

> than TLS 1.0 support, but that's just a detail.)

Instead of particular versions, it seems to me that an indicator of "I
tried to connect using a higher version than I'm using now but had to
fall back to this verion" would cover any case now or later.

The server would respond with an extension value indicating whether it
intends to communicate over the channel using the negotiated version or
not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
or SSLv3, for example.)  Both sides would continue the handshake through
completion to ensure that everything is legitimate.

Mike

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Sep 2013 20:47:45 +0300

This discussion seems to really be about enforcing the following policy:

If the client can speak TLS 1.X but the "network" (middlebox) only 
allows TLS 1.Y, then, even though the server will happily negotiate TLS 
1.Y with other clients, it will reject this client and will not allow it 
to connect from inside this network.

Organizations often enforce weird and misguided policies on their users, 
e.g. forcing them all to use IE6 so that "legacy applications" do not 
need to be upgraded. Mind you, those older browsers only speak older 
SSL/TLS versions and *their* connections will still go through! 
Employing such middleboxes is just another policy of this type. Is it 
really our business to counteract the organization's policy?

Thanks,
	Yaron

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Sep 2013 11:56:48 -0700

> to connect from inside this network.

No.  A server that is happy to use TLS 1.Y wouldn't reject the clients
who first tried 1.X.  The discussion is about adding a mechanism for a
client to inform the server that it couldn't connect using a higher
version, and then also for the server to acknowledge that back to the
client.

Such a mechanism would provide a way to detect problematic paths/routes,
i.e. middleboxes, and also any active downgrade attacks.

Mike

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Sep 2013 20:57:10 +0200

> fall back to this verion" would cover any case now or later.

Indeed that's what I ended up writing down for an Internet Draft.

> completion to ensure that everything is legitimate.

If everything *is* legitimate (and the implementations are correct), the
initial handshake with no downgrade should have gone through (and
negotiated the highest common version).  So I think all that's called for
if there's a problem with a downgraded connection is a fatal alert.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Sep 2013 21:00:41 +0200

> e.g. forcing them all to use IE6 so that "legacy applications" do not need
> to be upgraded. Mind you, those older browsers only speak older SSL/TLS
> versions and *their* connections will still go through! Employing such
> middleboxes is just another policy of this type. Is it really our business
> to counteract the organization's policy?
>

Certainly, because we don't know if "the organization" that's trying to
downgrade your connection are your local network admins, or a foreign
government agency.  This doesn't mean there couldn't be a knob allowing you
(or your admins) to disable the security check, but the protocol should
have means to detect this kind of problem.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Sep 2013 22:26:32 +0300

It's one thing to "detect" these cases. Such detection is probably more 
effective on the server side, where there are admins that look at log 
files. I agree we should be providing both sides with the information.

It's another thing to recommend that servers always drop such 
connections. I don't think we should do that.

Thanks,
	Yaron

On 09/25/2013 10:00 PM, Bodo Moeller wrote:
>
>     Organizations often enforce weird and misguided policies on their
>     users, e.g. forcing them all to use IE6 so that "legacy
>     applications" do not need to be upgraded. Mind you, those older
>     browsers only speak older SSL/TLS versions and *their* connections
>     will still go through! Employing such middleboxes is just another
>     policy of this type. Is it really our business to counteract the
>     organization's policy?
>
>
> government agency.  This doesn't mean there couldn't be a knob allowing
> you (or your admins) to disable the security check, but the protocol
> should have means to detect this kind of problem.
>

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Sep 2013 22:27:15 +0200

> Indeed that's what I ended up writing down for an Internet Draft.

Now here:

http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

Bodo

---

From: [email-masked] (Martin Rex)
Date: Wed, 25 Sep 2013 22:54:24 +0200 (CEST)

> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

OH NO, not again!!

Any kind of specification for TLS, that suggests to the server
to apply heuristics and make (often flawed or unjustified) assumptions
about what the client may want or may not want and have the _server_
abort the handshake rather than the client, are a REALLY BAD IDEA and
squarely against the IETF spirit to promote interop.

Fatal SSL alerts in particular, are worst of all, because they do often
do not give any clue, are not ever sent by a number of TLS implementations
(you just see the connection close/reset), and are hardly/poorly visualized
or not even accessible on many TLS clients.

If anything, then such a "downgrade protection discovery" signaling
cihper suites should cause the server to respond with a ServerHelloExtension
listing the features that the server supports and would be capable
of processing properly when present in ClientHello, and leave the
decision, whether to abort the handshake and whether to tell or ask
the user about any perceived problems first, entirely up to the client.

-Martin

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 26 Sep 2013 01:08:03 +0400

> the user about any perceived problems first, entirely up to the client.

[reference] http://www.ietf.org/mail-archive/web/tls/current/msg08892.html

---

From: [email-masked] (Martin Rex)
Date: Wed, 25 Sep 2013 23:09:54 +0200 (CEST)

Alfredo Pironti wrote:
> Peter Gutmann <[email-masked]> wrote:

Eric is correct, the definition of the MAC in Peter's draft is
obviously incorrect (and likely does not match Peter's implementation):

TLSv1.0:  https://tools.ietf.org/html/rfc2246#section-6.2.3.1

   The MAC is generated as:

       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
                     TLSCompressed.version + TLSCompressed.length +
                     TLSCompressed.fragment));

When changing from mac-pad-encrypt to encrypt-mac, as suggested
by Peter's draft, the MAC no longer operates on the TLSComressed PDU,
but on the TLSCiphertext PDU -- which results in:

       HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
                     TLSCiphertext.version + TLSCiphertext.length +
                     TLSCiphertext.fragment));

    The computation of TLSCompressed.length on receive changes slightly,
    because there no longer is a MAC trailing the data after decrypt.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Sep 2013 14:17:07 -0700

> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

I think that the server MUST send a FATAL alert only if it would
not have been willing to negotiate the lower TLS version in the
absence of the SCSV.

A WARNING alert from the server (or some extension_data with more
information) lets the client decide whether to continue.  Both
sides can keep track of these occurrences for further investigation
by interested admins at their leisure (not via calls to the help
desk).

Also RFC 3546 and 4366 have been obsoleted by RFC 6066.

Mike

---

From: [email-masked] (Martin Rex)
Date: Wed, 25 Sep 2013 23:25:32 +0200 (CEST)

>     because there no longer is a MAC trailing the data after decrypt.

I forgot:
Peter's proposal includes the CBC-IV in the MAC computation for TLSv1.0,
but this isn't technically necessary.  In TLSv1.1, the MAC _must_
include the IV, but the IV is already part of TLSCiphertext.

Curiously, for decrypt, the way the TLSv1.1 GenericBlockCipher PDU 
is specified, it uses a fixed zero IV and a block-sized "random confounder"
that is covered by the MAC, but ignored after decrypt (reminds me of Kerberos)

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 25 Sep 2013 23:32:17 +0200 (CEST)

> Also RFC 3546 and 4366 have been obsoleted by RFC 6066.

"Warning level alerts"?  Please don't!  As rfc6066 summarizes,
the last experiment of using warning level alerts failed badly
  -> "unpredictable client behaviour" and it is NOT RECOMMENDED.

Speaking of rfc 3546/4366/6066 "TLS Extensions":

  https://tools.ietf.org/html/rfc6066#section-3

                  If the server understood the ClientHello extension but
   does not recognize the server name, the server SHOULD take one of two
   actions: either abort the handshake by sending a fatal-level
   unrecognized_name(112) alert or continue the handshake.  It is NOT
   RECOMMENDED to send a warning-level unrecognized_name(112) alert,
   because the client's behavior in response to warning-level alerts is
   unpredictable. 

-Martin

---

From: "Paul Bakker" <[email-masked]>
Date: Thu, 26 Sep 2013 08:57:32 +0200

> Eric is correct, the definition of the MAC in Peter's draft is obviously
incorrect
> (and likely does not match Peter's implementation):
> 
> When changing from mac-pad-encrypt to encrypt-mac, as suggested by
> Peter's draft, the MAC no longer operates on the TLSComressed PDU, but on
> the TLSCiphertext PDU -- which results in:
> 

Please read my other reply on 'skipping' a layer somewhere in this thread.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Sep 2013 11:58:10 +0200

> squarely against the IETF spirit to promote interop.

(For my response, see thread "New Version Notification for
draft-bmoeller-tls-downgrade-scsv-00.txt"; I want to avoid hijacking this
one.)

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Sep 2013 11:56:28 +0200

2013/9/25 Michael D'Errico <[email-masked]>

> http://www.ietf.org/internet-**drafts/draft-bmoeller-tls-**
>> downgrade-scsv-00.txt<http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt>
>>
>

> by interested admins at their leisure (not via calls to the help

I guess this would work, but I also want to keep the protocol simple.  (If
the client wants to continue with the downgraded protocol, it can send a
downgraded ClientHello without the SCSV.  Sending the SCSV is RECOMMENDED,
not REQUIRED.)

> Also RFC 3546 and 4366 have been obsoleted by RFC 6066.

I know -- so have RFC 2246 and RFC 4346 (by RFC 4346 and by RFC 5246,
respectively), but all of these are still relevant for implementations of
older TLS versions.  (RFC 6066 alone doesn't tell you how extensions work
in TLS 1.0 or TLS 1.1.)

Bodo