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

Bodo Moeller <> Wed, 25 September 2013 11:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6A9E21F9FBF for <>; Wed, 25 Sep 2013 04:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R9TdqhVyPUTV for <>; Wed, 25 Sep 2013 04:03:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B3C5721F9BAB for <>; Wed, 25 Sep 2013 04:03:22 -0700 (PDT)
Received: from ( []) by (node=mreu3) with ESMTP (Nemesis) id 0Ljxmg-1VzVGk0R0U-00c9fA; Wed, 25 Sep 2013 13:03:20 +0200
Received: by with SMTP id wp18so6431450obc.22 for <>; Wed, 25 Sep 2013 04:03:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qTMMQAo0PYjl3FgLDpSNXNdkjcvO3tEGF6hQInlsUtU=; b=iVtxW5A4Dn297gfR1mAG4bNAVYMVRU60nf/iwXlgkiJH3DvQQDStvKyMkdwJzlY5Wg B6Ocd+MNJK670/8ntkK0qzaAK8UzdCqTKdYYzrQ+7cMVY3rb9SfT99pzQcBKj6lLGF9P ZWuYBZJoVtHSzpHSUaAm/40C6z0S6BFdIzfCt40pC8aCRPCLYmXpc8qgq/nqzh11TvrT CCpYmdVYjSs3oXAb5GGyMZO2YwFevL4IdnsmmMS1IqfyJHJEUFf75t3VcBKlcm0/KSK8 66VjWKK4+CUBp8UNpn8bndvineK704OQLP5HpS293MxGYLOi5/udJOoPPqR4bW9BBI/W VHgQ==
MIME-Version: 1.0
X-Received: by with SMTP id e4mr29810787oes.23.1380106998896; Wed, 25 Sep 2013 04:03:18 -0700 (PDT)
Received: by with HTTP; Wed, 25 Sep 2013 04:03:18 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 25 Sep 2013 13:03:18 +0200
Message-ID: <>
From: Bodo Moeller <>
To: Peter Gutmann <>
Content-Type: multipart/alternative; boundary=001a11c257d46be24904e733330f
X-Provags-ID: V02:K0:vKbBx7MAXyqsX3BHLeJhNlUBmetwUc0f1BDa4AiiWpf u6JsEIKaQcBgdWhUMEgVm7jl6klknbNsKZnJqHpP+6fa80VDet Kgq9hAuG9OoY299byBzwpLqw5Iq+CubXpa/YTFHxwXwtzCqKCo v54uhwEGihk0ryEu4sXYQpnXJQD87YYHCqi8HHU2W4IW6ldNlw FKjfJ6fA7Vv6hayx5cVFefka4u4oAaAA1IHkS6XpS6+77ZTg3q 1URTEHcbqFUL28XfAuQEtnyPwmuSCXs7nRj4pG6ZVQx3aP2i3X 4vgO6O7uX1JA85F6UVAqsTgLJM+i9yOvzI1R1P3QzLT4gjDhso h2PMskAYTl0IBCgZO0yO2lBPGGaqp9bvPbiGeu2h0vkx3NVBen nanU/+cmAZL2GITiT3nC3jc+novusz529jQlaJhLDwZwkyLD3J P0aEP
Cc: "<>" <>
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Sep 2013 11:05:38 -0000

> > - Because this draft relies on extensions, it seems not to resist
> >   active attack when clients do insecure version fallback
> >   (see for instance:
> >
> 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.

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:

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