Re: [TLS] Fresh results

Watson Ladd <watsonbladd@gmail.com> Thu, 03 December 2015 23:45 UTC

Return-Path: <watsonbladd@gmail.com>
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 9F3911AC3C5 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 15:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level:
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 PXfkYDp3Wt1r for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 15:45:15 -0800 (PST)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2E11AC3AB for <tls@ietf.org>; Thu, 3 Dec 2015 15:45:15 -0800 (PST)
Received: by ykdv3 with SMTP id v3so105729074ykd.0 for <tls@ietf.org>; Thu, 03 Dec 2015 15:45:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lLMAHE3+b8gQeil4pF1RDWYaHSUaCuhMvKrZ2VRWbIc=; b=j+WjwvjkmJdaKILnFVHKDSl1Q/Zfp7HniF5EqJ9tWwtlESOQe3JCLDsvgtEQw+ziKZ WqBhhawGC3ezlDr9UpskzcS2a3b9pHnfXgzca5iFdzk50ob9mZbcJ9c4I0ylU4ma5Phr 0zTECeAEA5x4KpS+IfvRlHeZZcgkbZPhLrM7pk14d5PrtDvA6mc8crmfiOme6MtFt59W 5g15pZytUERr14ipIWhvQ4U+oZ+vWJtjPoMWbtdGc4nvgrZI0AcraaiB2xbQ/lxmAXTg O8+ztnCHOukxp93ip8k36bVgsg/AK0TSwKcDZe6hW9JKbfSlBySnmiKCO9Zjwn62eUM7 VvTA==
MIME-Version: 1.0
X-Received: by 10.13.193.6 with SMTP id c6mr9135989ywd.326.1449186314417; Thu, 03 Dec 2015 15:45:14 -0800 (PST)
Received: by 10.129.148.131 with HTTP; Thu, 3 Dec 2015 15:45:14 -0800 (PST)
In-Reply-To: <20151201210257.64f1a7a5@pc1>
References: <CACsn0cm41VD40tiwR-sO9piPu01rRkoWKPwHWCKcr5Z9id8kDg@mail.gmail.com> <20151201210257.64f1a7a5@pc1>
Date: Thu, 03 Dec 2015 18:45:14 -0500
Message-ID: <CACsn0ckkqhmH82P=NOaRF9J+EYBf=4HwfaBXKMvkp2QGdmnqNA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Hanno Böck <hanno@hboeck.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/z-swAwAynCb_D3F6FdaXF_R82Rc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fresh results
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Dec 2015 23:45:16 -0000

On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck <hanno@hboeck.de> wrote:
> On Tue, 1 Dec 2015 14:28:49 -0500
> Watson Ladd <watsonbladd@gmail.com> wrote:
>
>> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf
>>
>> This one looks very nasty to fix. Short of disallowing the use of RSA
>> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I
>> don't see a good fix. I haven't read this paper in detail yet.
>>
>> Cross-protocol attacks are the gift that keeps giving.
>
> Correct me if I'm wrong, but as I understand the result (and I had one
> of the authors explaining it to me a few days ago) the problem appears
> only if you have a TLS 1.2 implementation with an RSA keyexchange that
> is vulnerable to a bleichenbacher attack. If it is not then you're fine.
>
> So as long as you make sure you implement all the proper
> countermeasures against that you should be fine. (Granted: This is
> tricky, as has been shown by previous results, even the OpenSSL
> implementation was lacking proper countermeasures not that long ago,
> but it's not impossible)

Can you describe the complete set of required countermeasures, and
prove they work comprehensively? What if the code is running on shared
hosting, where much better timing attacks are possible? What's
shocking is that this has been going on for well over a decade: the
right solution is to use robust key exchanges, and yet despite knowing
that this is possible, we've decided to throw patch onto patch on top
of a fundamentally broken idea. There is no fix for PKCS 1.5
encryption, just dirty hacks rooted in accidents of TLS.

>
> Deprecating the RSA keyexchange just became a bit harder with Google's
> intent to deprecate DHE in Chrome and use RSA as the fallback if the
> host doesn't do ECDHE.
>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: BBB51E42
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.