Re: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

Bodo Moeller <bmoeller@acm.org> Tue, 21 October 2014 07:19 UTC

Return-Path: <SRS0=D4s1=7M=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1A1A6FBF for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 00:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClslL8KjtG46 for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 00:19:07 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38401AD068 for <tls@ietf.org>; Tue, 21 Oct 2014 00:19:06 -0700 (PDT)
Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0McWDw-1XOwps290i-00Hf7r; Tue, 21 Oct 2014 09:19:04 +0200
Received: by mail-yh0-f42.google.com with SMTP id t59so877249yho.29 for <tls@ietf.org>; Tue, 21 Oct 2014 00:19:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.110.35 with SMTP id t23mr12338673yhg.126.1413875942407; Tue, 21 Oct 2014 00:19:02 -0700 (PDT)
Received: by 10.170.194.15 with HTTP; Tue, 21 Oct 2014 00:19:02 -0700 (PDT)
In-Reply-To: <CAFewVt7TLPpp32_DNAQowXkfQ=CEZ5e=DKEX7UYSDa_Cdyq+ag@mail.gmail.com>
References: <CAFewVt62pXB8+gv5ozPFSvzYeW-MJgE-61dRLpQUEWWs+0UX-A@mail.gmail.com> <CADMpkcJGbwY9R2tQ+t0=HbhWcnqecY8r6FCW=L5Q-K89D+2mcA@mail.gmail.com> <CAFewVt7TLPpp32_DNAQowXkfQ=CEZ5e=DKEX7UYSDa_Cdyq+ag@mail.gmail.com>
Date: Tue, 21 Oct 2014 09:19:02 +0200
Message-ID: <CADMpkcL=GPNhN6FSvJjpqYMdvuqhhAeCb-UBHY=67uP_XA00=w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1133358a4dc6160505e9a588"
X-Provags-ID: V02:K0:SX8hH6DOp6floV40EaKFyJIZMY6nAb+JZNomFkJxbXs BbD7iqITmmt2eOXrIWuXfsqvL60dI74SFhLwCO042jiMSvGqwe JJHc8bR23ifL4oCMeDX+8PvkSlsjLmZw/wm+mEIfCVHIC51hyu 7KTUZAfQMZTi84BriLdO5Us+32Ecl9iFhykiKh1oj2e0RgfV2J WZ6F8eCESZjqv9q/vzDb6H/bGP6i4rrzkB+BYFkbfaAUHCuYMi RNabCrLqZtVZVUtBIF/aupvV98nsqfVr5CqPmOEAmKbVLVldRF WwBJdLBlf134ZQZw6E05Ypv9VSgPwDfvKFjJwTqRXVrgDGsJ4Z JqeNEoJeFayfqoJGv9MCsZ+45YW9CgvcvkNCeWLPsxks0T0wwc iNzprh0Kx/JSS0di/qUNIwqP37nYbGU3rMVw1mfLfqdw3gEJU7 ixsKQ
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d8G0VaviRpVIw64Tye2LIAmVhSY
Subject: Re: [TLS] POODLE applicability to TLS 1.0+ (was Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2014 07:19:08 -0000

Brian Smith <brian@briansmith.org>:

My main concern is that we do not know how many TLS 1.0 servers actually
> check the padding, but we've assumed that all of them do, even though TLS
> 1.0 does not require checking the padding.


While the spec could be better, it clearly does expect implementation to
check the padding. (The alternative reading, as far as I can see, would be
that checking the MAC isn't required either.)



> For strong protection against bugs in old protocol versions, the only
>> option is to disallow those versions completely.
>>
>

> Yes, but TLS 1.0 implementations can mitigate the risk, as most do, by
> checking the padding conforms to the TLS 1.0 requirements.
>
> And, so can SSL 3.0 implementations, right? Checking that SSL 3.0 CBC-mode
> records conform to the TLS 1.0 padding rules is likely to cause some
> interop problems, but those interop problems would be much less severe than
> disabling SSL 3.0 completely, right?
>

Some implementations do indeed use TLS 1.0-style padding with SSL 3.0, but
not all do, and SSL 3.0 has too many other problems to be worth keeping
alive.

Bodo