Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3

mrex@sap.com (Martin Rex) Thu, 27 March 2014 00:04 UTC

Return-Path: <mrex@sap.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 E8CF21A0406 for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 17:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.552
X-Spam-Level:
X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_BACKHAIR_57=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 DlxORhB-YQPf for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 17:04:34 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id F17071A03FE for <tls@ietf.org>; Wed, 26 Mar 2014 17:04:33 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s2R04Vlg004504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 01:04:31 +0100 (MET)
In-Reply-To: <5EED826F-4736-4331-B7B8-8C73DA6F5ACA@rtfm.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Mar 2014 01:04:31 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140327000431.2C8821AC7D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Jy8BPGTMRCSZUdPtlV08h35oxrM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 27 Mar 2014 00:04:36 -0000

Eric Rescorla wrote:
> 
> This is more an http issue than a tls issue but we pretty much have
> to go with the Web we have which includes (restricted) cross origin
> requests subject to the same origin policy.

Eric, in principle I'm with you.  The TLS WG needs to take into account
real world usage scenarios or it will cease to be a useful technology.

But we are having a real problem that folks a looking at TLS to be
"magic pixie dust", and the perception that any apps or protocol design,
no matter what design flaws it has, will automatically become secure
by adding TLS to it.


I don't see a solution for the disclosing authentication (=passwords)
at the human<->machine interface, not even on the horizon.


But the disclosing authentication on pure machine<->machine interfaces
(including "SSL Cookies") provides ample opportunity for new security
problems, and I'm seeing that TLS channel encryption is (ab)used to
excuse the continued use of disclosing authentication on what is
pure machine<->machine interfaces, and that train is heading in
the wrong direction.


-Martin