Re: [TLS] Minutes from Tuesday

Bodo Moeller <bmoeller@acm.org> Wed, 05 November 2014 08:30 UTC

Return-Path: <SRS0=YCei=73=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 5B0441A8828 for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 00:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.677
X-Spam-Level:
X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 QICtId90YjKT for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 00:30:26 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 EE9581A8824 for <tls@ietf.org>; Wed, 5 Nov 2014 00:30:25 -0800 (PST)
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Lw14n-1Y6LiM1BzJ-017lJe; Wed, 05 Nov 2014 09:30:23 +0100
Received: by mail-ob0-f170.google.com with SMTP id nt9so208084obb.15 for <tls@ietf.org>; Wed, 05 Nov 2014 00:30:22 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.202.225.212 with SMTP id y203mr23745164oig.16.1415176222144; Wed, 05 Nov 2014 00:30:22 -0800 (PST)
Received: by 10.60.32.42 with HTTP; Wed, 5 Nov 2014 00:30:22 -0800 (PST)
In-Reply-To: <545514AE.9080100@polarssl.org>
References: <20141031012622.2D0721AF6E@ld9781.wdf.sap.corp> <545514AE.9080100@polarssl.org>
Date: Wed, 05 Nov 2014 09:30:22 +0100
Message-ID: <CADMpkc+3wPmi41gvgi4w1kNyfE7-g9DMb0C7_eXnVvPbduX=Yg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>
Content-Type: multipart/alternative; boundary="001a113d2dfe0400ae050718640e"
X-Provags-ID: V02:K0:jg4q5ljdJ/1rQ1etIK91Wybkcj91bLztc5fX1GHUApl vKIPs9L3jCUf69/bCuSDTSB0FiuFwfAndAoF2pWNydAQSMZwpt gWIjOzDAYypJz+L1j5v1YAnKpgyLUWjKy8cqkvW+Qb7C+91caN eHEOrfziPb2hFK38EIIkFEU1gkwNCsKULACzdnffEVnKUyR2Ki V5VbwHi/JCpMNDDl82I/GaEUI4Fg74CsIpWwhy622KFjPJRcpi RJHHbMpKqOIjdFESKvOgTyHydpFYoVgfoFZ0ItjdzQ8ucK6La1 +zV7SZm6PFHB9WpDeikRmLdIKEFqlLuaWI1hpgSy0WTwNsVrBb grKOq+j+7/Asd8AlkHqjMF1UNT9lWO74Eo63erBgku/v5Tt66d V4yVjpsMmgbU9pSfsCBtK6ON3te/TyYB4yxdrCn15K6eReYAZ0 jgrWN
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Nf2vhsBYcCFN4FFcaONmpWmP_Ds
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Minutes from Tuesday
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: Wed, 05 Nov 2014 08:54:21 -0000

Manuel Pégourié-Gonnard <mpg@polarssl.org>:

> Martin Rex wrote:
> > Bodo Moeller wrote:



> >> [...] reacting to a fatal alert is something that all TLS
> >> implementations already know how to do.
>


> > 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.
>


> I'm not so sure. There are already a lot of situations where
> implementations are
> requires to make the handshake fail, eg if the verify data from the
> Finished
> message don't match, which indicates the handshake data has been tampered
> with.
> This is not entirely different, the main difference is that the suspected
> tampering happened during the previous handshake.
>
> I'm not saying breaking the handshake is the only right thing to do, I can
> see
> the benefits of the solution you suggest, but I think the simplicity of the
> current draft is a big advantage in getting it widely (and correctly)
> deployed
> sooner rather than later, which IMO outweighs the advantages of a more
> complex
> approach.
>

Right. If we figure out how to make more handshakes succeed immediately
without a fallback dance, that's completely orthogonal to TLS_FALLBACK_SCSV
(which won't be needed in such handshakes).

Any such proposal will be considerably more complex than the
TLS_FALLBACK_SCSV mechanism, and I think there's no excuse for allowing
downgrade attacks to happen until it is deployed.

Bodo