From pascal.urien@gmail.com  Thu Sep  6 23:35:47 2012
Return-Path: <pascal.urien@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C172C21E8050 for <tls@ietfa.amsl.com>; Thu,  6 Sep 2012 23:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8G1DmhVUpBa for <tls@ietfa.amsl.com>; Thu,  6 Sep 2012 23:35:47 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E41EA21E8034 for <tls@ietf.org>; Thu,  6 Sep 2012 23:35:46 -0700 (PDT)
Received: by wibhr14 with SMTP id hr14so1857451wib.13 for <tls@ietf.org>; Thu, 06 Sep 2012 23:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=188ej3MxP7nKzsirzlebV+kSQqokcEmY19veV6gvUNw=; b=cdV7VB2M72bIL7fXhaEjKROKkFeJ2k7rkXdLfpnwzGCbWt4cU0DlMie+vpGNDSYE3e 5jdUH6aIXtEEyf037i3dMy6PDyehOUATQyUdEpz9JmFktoiHxNzJrVk4Xwkf1N6t0akq WL1fkI6JWBdgP4h02BYBioldxwfi71ET8retmpDLhFmhtO3RC5dlCLiZ7pef+HS93MRE 1JXrHzYBpkidJJlZISE3680bFLJNZaSulongr0qjqB7RTtOKbDekv52/VgxAalcdh3ZV jyhm3lL7UqZVHGGhjxmJWd0iwJBnn9EcQLNT2IbGmacQDR3n5Wdig7KO37Jg0lCUKc3k 97yg==
MIME-Version: 1.0
Received: by 10.180.100.131 with SMTP id ey3mr9897854wib.15.1346999745742; Thu, 06 Sep 2012 23:35:45 -0700 (PDT)
Received: by 10.194.32.66 with HTTP; Thu, 6 Sep 2012 23:35:45 -0700 (PDT)
Date: Fri, 7 Sep 2012 08:35:45 +0200
Message-ID: <CAEQGKXSK5RgM9qH0X+KtKFOYSyyE-WOhBDouAnUKK2aDVV2Wmw@mail.gmail.com>
From: Pascal Urien <pascal.urien@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=f46d0444ec195b88a904c916d110
Subject: [TLS] draft-urien-tls-llcp-00.txt
X-BeenThere: tls@ietf.org
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." <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: Fri, 07 Sep 2012 06:35:47 -0000

--f46d0444ec195b88a904c916d110
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

  LLCPS is a new draft for the support of TLS over LLCP, see

 http://tools.ietf.org/html/draft-urien-tls-llcp-00

 " This document describes the implementation, named LLCPS, of the TLS
   protocol over the NFC (Near Field Communication) LLCP layer. The NFC
   peer to peer (P2P) protocol may be used by any application that
   needs communication between two devices at very small distances (a
   few centimeters). LLCPS enforces a strong security in NFC P2P
   exchanges, and may be deployed for many services, in the Internet Of
   Things ecosystem, such as access control or ticketing operations."

NFC is a radio technology communication working at 13,56 Mhz and available
in many smartphones.
The target of the LLCPS protocol is to secure IoT servicessuch as access
control  (electronic keys,..), or payments

Regards

Pascal

--f46d0444ec195b88a904c916d110
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div>
<div>=A0</div>
<div>=A0 LLCPS is a new draft for the support of TLS over LLCP, see</div>
<div>=A0</div>
<div>=A0<a href=3D"http://tools.ietf.org/html/draft-urien-tls-llcp-00">http=
://tools.ietf.org/html/draft-urien-tls-llcp-00</a></div>
<div>=A0</div>
<div>=A0&quot; This document describes the implementation, named LLCPS, of =
the TLS<br>=A0=A0 protocol over the NFC (Near Field Communication) LLCP lay=
er. The NFC<br>=A0=A0 peer to peer (P2P) protocol may be used by any applic=
ation that<br>
=A0=A0 needs communication between two devices at very small distances (a<b=
r>=A0=A0 few centimeters). LLCPS enforces a strong security in NFC P2P<br>=
=A0=A0 exchanges, and may be deployed for many services, in the Internet Of=
<br>=A0=A0 Things ecosystem, such as access control or ticketing operations=
.&quot;</div>

<div>=A0</div>
<div>NFC is a radio technology communication working at 13,56 Mhz and avail=
able in many smartphones.</div>
<div>The target of the LLCPS protocol is to secure IoT servicessuch as acce=
ss control=A0=A0(electronic keys,..), or payments</div>
<div>=A0</div>
<div>Regards</div>
<div>=A0</div>
<div>Pascal</div>
<div>=A0</div>
<div>=A0</div>
<div>=A0</div>
<div>=A0</div>

--f46d0444ec195b88a904c916d110--

From internet-drafts@ietf.org  Wed Sep 12 08:38:39 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE521F8602; Wed, 12 Sep 2012 08:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level: 
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlY115bDOhlR; Wed, 12 Sep 2012 08:38:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C6621F8532; Wed, 12 Sep 2012 08:38:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120912153839.5849.52156.idtracker@ietfa.amsl.com>
Date: Wed, 12 Sep 2012 08:38:39 -0700
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-13.txt
X-BeenThere: tls@ietf.org
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." <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, 12 Sep 2012 15:38:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Transport Layer Security Working Group of=
 the IETF.

	Title           : Transport Layer Security (TLS) Cached Information Extens=
ion
	Author(s)       : Stefan Santesson
                          Hannes Tschofenig
	Filename        : draft-ietf-tls-cached-info-13.txt
	Pages           : 16
	Date            : 2012-09-12

Abstract:
   Transport Layer Security (TLS) handshakes often include fairly static
   information, such as the server certificate and a list of trusted
   Certification Authorities (CAs).  This information can be of
   considerable size, particularly if the server certificate is bundled
   with a complete certificate path (including all intermediary
   certificates up to the trust anchor public key).

   This document defines an extension that omits the exchange of already
   available information.  The TLS client informs a server of cached
   information, for example from a previous TLS handshake, allowing the
   server to omit the already available information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-cached-info-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-cached-info-13


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From jsalowey@cisco.com  Sun Sep 16 21:10:10 2012
Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6056B21F8545 for <tls@ietfa.amsl.com>; Sun, 16 Sep 2012 21:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EAZ9xLXqC-A for <tls@ietfa.amsl.com>; Sun, 16 Sep 2012 21:10:09 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA421F8484 for <tls@ietf.org>; Sun, 16 Sep 2012 21:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=160; q=dns/txt; s=iport; t=1347855009; x=1349064609; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YUb7Mf/h6Pu6DMOmdv0Guv80RSeGw0pRtqUz5Te2Clw=; b=igSU+w80oDItBQB6LEFU+tL1A8YpenA0m7l5FD8GOLwF8v8Xi3eagcNF vCt4MtbNASGFdV49YRDAXM67iD455lshJA6+tlEYmVHMxWwfk+qZGZaFd DjFWiglPOVI67dHz9Jqmmhd4rj7dDg3uFeRIHXl0ZTaLhCFbgHiESJkd3 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEOiVlCtJV2b/2dsb2JhbABFvBSBB4InEgEKHVEBPkInBDWHXpk/gSifJ4shhghgA5VijjiBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,433,1344211200"; d="scan'208";a="122187801"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 17 Sep 2012 04:10:09 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8H4A9pW005968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tls@ietf.org>; Mon, 17 Sep 2012 04:10:09 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Sun, 16 Sep 2012 23:10:08 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Working Group Last Call for draft-ietf-tls-cached-info-13
Thread-Index: AQHNlIpS3klSGbwVeE6POKXHr7ra2A==
Date: Mon, 17 Sep 2012 04:10:08 +0000
Message-ID: <037043A7-AFA7-4D4F-B1FD-1D3C229CC6A0@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.248.236]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19186.002
x-tm-as-result: No--26.831100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <171D3CBFF17BC94F99FAFA84C9B7876D@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] Working Group Last Call for draft-ietf-tls-cached-info-13
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 04:10:10 -0000

This is an announcement of working group last call for draft-ietf-tls-cache=
d-info-13.   Please send you comments to the TLS list by October 8, 2012. =
=20



From rob.stradling@comodo.com  Mon Sep 17 00:50:44 2012
Return-Path: <rob.stradling@comodo.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E1D21F84A7 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 00:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRjZCDUQ3J0N for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 00:50:40 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4870D21F846C for <tls@ietf.org>; Mon, 17 Sep 2012 00:50:39 -0700 (PDT)
Received: (qmail 23201 invoked from network); 17 Sep 2012 07:50:38 -0000
Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 17 Sep 2012 07:50:38 -0000
Received: (qmail 11468 invoked by uid 1000); 17 Sep 2012 07:50:38 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 17 Sep 2012 08:50:38 +0100
Message-ID: <5056D64D.9020007@comodo.com>
Date: Mon, 17 Sep 2012 08:50:37 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <037043A7-AFA7-4D4F-B1FD-1D3C229CC6A0@cisco.com>
In-Reply-To: <037043A7-AFA7-4D4F-B1FD-1D3C229CC6A0@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-cached-info-13
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 07:50:45 -0000

Would it be possible to add support for cached CertificateStatus 
messages (see RFC 6066 Section 8 "Certificate Status Request") ?

On 17/09/12 05:10, Joseph Salowey (jsalowey) wrote:
> This is an announcement of working group last call for draft-ietf-tls-cached-info-13.   Please send you comments to the TLS list by October 8, 2012.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From n.mavrogiannopoulos@gmail.com  Mon Sep 17 04:28:06 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B9821F844D for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 04:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNqu1ZDEnNJ5 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 04:28:06 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49B7B21F844F for <tls@ietf.org>; Mon, 17 Sep 2012 04:28:02 -0700 (PDT)
Received: by vbbfc26 with SMTP id fc26so7808488vbb.31 for <tls@ietf.org>; Mon, 17 Sep 2012 04:28:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=f8tu43kPgcKbHJ9/F5P15WrhEnhl8iczlsO2mF7i6jQ=; b=ExcKj5LZqDS7GKwJVXX2PjLrtK+YBbrOZMLs91mMf6kHDpCxmj1OHrtuxUZlD93GsG X4Y4PGJLqDsouWx8f7DOGR1LGsVNnk8GtXrpHlfXWOex/hOez9stlLUmoE4n75eMmraM IGYBQDZ4KQUqtjSYuaqQlAlzTF5Cbk7mu/50QtvYcIzaYn7L7XuPH6HrvDSxvHg8tRGv fnAW8ACJzmiaw+2DixTlZVnkFz6NXeLYL9F3icd/o6xV8N/Tt/BebaQB3uEyc38PAABd lbBEFgs26xfH7Ch1Nw+gpeQnJT+Qlrrlz3ZpEYVuTkAIoaSHTPzjgkwg7XMnBs7RZBlC 8vPw==
MIME-Version: 1.0
Received: by 10.220.221.203 with SMTP id id11mr7169294vcb.42.1347881281605; Mon, 17 Sep 2012 04:28:01 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.58.248.97 with HTTP; Mon, 17 Sep 2012 04:28:01 -0700 (PDT)
In-Reply-To: <037043A7-AFA7-4D4F-B1FD-1D3C229CC6A0@cisco.com>
References: <037043A7-AFA7-4D4F-B1FD-1D3C229CC6A0@cisco.com>
Date: Mon, 17 Sep 2012 13:28:01 +0200
X-Google-Sender-Auth: YK29b4DKqs2QaJUwpOIomw4XSj4
Message-ID: <CAJU7za+AJa22GbhE9DU5RdmkqEoPB6_ou5tr5_4U7Vv2ac-C+Q@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-cached-info-13
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 11:28:06 -0000

On Mon, Sep 17, 2012 at 6:10 AM, Joseph Salowey (jsalowey)
<jsalowey@cisco.com> wrote:

> This is an announcement of working group last call for draft-ietf-tls-cached-info-13.   Please send you comments to the TLS list by October 8, 2012.

Is there any implementation of this draft? I'd be against publishing
an RFC if there has been no implementation of it, because several
missing details may go undetected.

regards,
Nikos

From rob.stradling@comodo.com  Mon Sep 17 04:38:54 2012
Return-Path: <rob.stradling@comodo.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C738E21F8623 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 04:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ9liBhjoW3B for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 04:38:54 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8AE21F8608 for <tls@ietf.org>; Mon, 17 Sep 2012 04:38:46 -0700 (PDT)
Received: (qmail 23733 invoked from network); 17 Sep 2012 11:38:43 -0000
Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 17 Sep 2012 11:38:43 -0000
Received: (qmail 17570 invoked by uid 1000); 17 Sep 2012 11:38:43 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 17 Sep 2012 12:38:43 +0100
Message-ID: <50570BC3.2040102@comodo.com>
Date: Mon, 17 Sep 2012 12:38:43 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <037043A7-AFA7-4D4F-B1FD-1D3C229CC6A0@cisco.com> <CAJU7za+AJa22GbhE9DU5RdmkqEoPB6_ou5tr5_4U7Vv2ac-C+Q@mail.gmail.com>
In-Reply-To: <CAJU7za+AJa22GbhE9DU5RdmkqEoPB6_ou5tr5_4U7Vv2ac-C+Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-cached-info-13
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 11:38:54 -0000

I'm not aware of any implementations of draft 13.

AGL wrote patches for NSS and OpenSSL based on draft 07:
http://www.ietf.org/mail-archive/web/tls/current/msg05983.html

On 17/09/12 12:28, Nikos Mavrogiannopoulos wrote:
> On Mon, Sep 17, 2012 at 6:10 AM, Joseph Salowey (jsalowey)
> <jsalowey@cisco.com> wrote:
>
>> This is an announcement of working group last call for draft-ietf-tls-cached-info-13.   Please send you comments to the TLS list by October 8, 2012.
>
> Is there any implementation of this draft? I'd be against publishing
> an RFC if there has been no implementation of it, because several
> missing details may go undetected.
>
> regards,
> Nikos
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From n.mavrogiannopoulos@gmail.com  Mon Sep 17 14:14:22 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE40721E804E for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 14:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n6sU4Ss2u5L for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 14:14:22 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0321E803D for <tls@ietf.org>; Mon, 17 Sep 2012 14:14:21 -0700 (PDT)
Received: by eekb45 with SMTP id b45so3697023eek.31 for <tls@ietf.org>; Mon, 17 Sep 2012 14:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=cjFSeyJsrQ8CcbDsxh0pswy+Kak6XU226zvEb6Yx4tQ=; b=AeKj49VFgnHI30887ir4I/WRL/ME1G6LN/Xd1VPfQ4HeyTGQO01n2Mj93s056+K6vI whFQ4D3fLgsp32yDsiAUoTmKf61X73z7TKGOjcB+m/Nvd18c2U8CukLwVuZ+8tUq4pdw cE64M7tPk6GCrr+LMK1+0YFq41f13X/ZhjQBGDIuH4AGS7biZ+95Vqw44ZzNs1+VFB+O a4SCHQPNwdudYHhX8QqVzYlzEJ8xNip0yqFzhfQ96HH/3gOT0zvDmgHWVTaYIuGwq/P2 wcz7tcxyG9AnTVajVORfu8JYS5JEuwkx8lBaYKjlGtWkZ/FvTxkVa5v3SNAaoIaK7EZw ve5Q==
Received: by 10.14.218.5 with SMTP id j5mr15101179eep.16.1347916460939; Mon, 17 Sep 2012 14:14:20 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id r45sm30832412eem.6.2012.09.17.14.14.19 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 14:14:20 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <505792AB.5000207@gnutls.org>
Date: Mon, 17 Sep 2012 23:14:19 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 21:14:22 -0000

Hello,
 I'm wondering how other implementers mitigated the Rizzo's attack on
TLS compression [0]. What I've currently done is to suggest:
1. to disable compression
2. If you need compression use CBC random padding

and I plan to add a stateless compression mode (which violates RFC3749).
Any other ideas?

regards,
Nikos


[0].
http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/

From simon@josefsson.org  Mon Sep 17 14:29:16 2012
Return-Path: <simon@josefsson.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC321F8618 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 14:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.791
X-Spam-Level: 
X-Spam-Status: No, score=-99.791 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2A23dBYrXm8 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 14:29:15 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 71AC821F8616 for <tls@ietf.org>; Mon, 17 Sep 2012 14:29:14 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q8HLT4RG001109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Sep 2012 23:29:06 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <505792AB.5000207@gnutls.org>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120917:nmav@gnutls.org::7v5AeSEkEUpwvOjQ:Ngoz
X-Hashcash: 1:22:120917:tls@ietf.org::jNwzao7GjUpIY/w3:bykj
Date: Mon, 17 Sep 2012 23:29:03 +0200
In-Reply-To: <505792AB.5000207@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 17 Sep 2012 23:14:19 +0200")
Message-ID: <87d31knxsw.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 21:29:16 -0000

Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:

> Hello,
>  I'm wondering how other implementers mitigated the Rizzo's attack on
> TLS compression [0]. What I've currently done is to suggest:
> 1. to disable compression
> 2. If you need compression use CBC random padding
>
> and I plan to add a stateless compression mode (which violates RFC3749).
> Any other ideas?

I'm curious, how would a stateless compression scheme work?  Compress
each record separately?  Is that enough to fix this?  I'm thinking some
applications might concatenate data from different origins into the same
TLS record anyway.

/Simon

From agl@google.com  Mon Sep 17 14:33:49 2012
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FF821F8444 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 14:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z0M69o0wXlT for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 14:33:48 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6017321F8440 for <tls@ietf.org>; Mon, 17 Sep 2012 14:33:48 -0700 (PDT)
Received: by iec9 with SMTP id 9so2149212iec.31 for <tls@ietf.org>; Mon, 17 Sep 2012 14:33:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=ODq6PtBiqVtL0hchLtuIFHz074Muvf0Q5O5bdNyf2gc=; b=DOZHJXL8TMQNbyWrp5mfTnM9FF8puqxNbl44/mSwnCfRaUaFgT0kFrpelazYhGtX+i udk4YQVXQY4+YCX9eniiaIq0WU/LA4771sz6buZBoUTwUQevpvmwY7PhWhXbKw03Sx4/ bxfSCiFdORfrnadMzfXPSlHN/vLKUGhQRLNPldBni3CMiZbUeVP/ybiQInVQTNm9Acyw 2sj4T0gUtk9gu2SIcUq80PTUcm6TJKnBR7n9thnvTuMx3RHcTDY80gjg4mtH9D0dyd5K JI+YqNnpBQxm3xSTtazZjlOTxEDnZmUTmNPKcKikT+aq91Nw3d2gUTWWv3eAbxP2Z8Ph pQhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ODq6PtBiqVtL0hchLtuIFHz074Muvf0Q5O5bdNyf2gc=; b=mB+uS06NUK9uag5SkvWIlw3DpIwVrzWvgs4KiRo9Fr6KLXI4t+yYQ0WbZA4cxjrOjv h6G/sQinRn4Vznh9t7dpp2Yb2OTVYVC3EQbxP7tl0bfAWEP+eVIGNyCUrjZ5d9olyynl WBlc+bVpYPEMHqDZWNTt9FezeE5IJG4GC/WQSL7SrBCwwkyoxQn+o1bWQyxzBqqbUI11 TbUftruCbWc0zmBZZKbvFF1uxMGTQaGWqb2IBNOwr/o8EC07sJi+GMzu/GiyvagWVVDr 62geQmMzAh3HQGy5iKHw2MhMerc4b2DtP5g1zevme8psCBcUjZ03t+o833yuWw1QGKSY oC7g==
Received: by 10.43.9.3 with SMTP id ou3mr10047710icb.14.1347917627934; Mon, 17 Sep 2012 14:33:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.9.3 with SMTP id ou3mr10047701icb.14.1347917627844; Mon, 17 Sep 2012 14:33:47 -0700 (PDT)
Received: by 10.231.224.84 with HTTP; Mon, 17 Sep 2012 14:33:47 -0700 (PDT)
In-Reply-To: <87d31knxsw.fsf@latte.josefsson.org>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org>
Date: Mon, 17 Sep 2012 17:33:47 -0400
Message-ID: <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Simon Josefsson <simon@josefsson.org>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmleza0TxZqb805DnyKkOPJAOtpIcFQagT8LOZEcN+yz5EnfbRtOjjOx2Dj6xtsGIzRN0e3ZOT1UVAE7Zr4WSPd1+ZW8c6FkHXm18n8pHBgg34QwlAvPfzV8jkPPwqZErDIePXlTbAag63zDWzUC2LKug5CyBqH7R+fL5NNlET0WeK6lWOiDoXQ5wR7jQyaulDqZ1ha
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 21:33:49 -0000

On Mon, Sep 17, 2012 at 5:29 PM, Simon Josefsson <simon@josefsson.org> wrote:
> I'm curious, how would a stateless compression scheme work?  Compress
> each record separately?  Is that enough to fix this?

(We're still keeping quiet about the details of this attack at the
request of the researchers.)

A per-record compression scheme could be implemented in a backward
compatible fashion with zlib, but is insufficient to stop the attack.


Cheers

AGL

From n.mavrogiannopoulos@gmail.com  Mon Sep 17 15:17:47 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AFE21F846E for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx7pVbzf8SV2 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:17:47 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 357BA21F8468 for <tls@ietf.org>; Mon, 17 Sep 2012 15:17:47 -0700 (PDT)
Received: by eekb45 with SMTP id b45so3710633eek.31 for <tls@ietf.org>; Mon, 17 Sep 2012 15:17:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=Sn2TjRfsq3a5Zn177ooyrvmpErJ7g8FbWl70pqv+gFE=; b=TIotStoorVXFEyBHwlQltqFjuLEohKA4OZpcmcYqow0jo7NERMWyG7QUKL7EhnGFJJ NLzmlbq584UeRwXIEjooFHllzyQTkuUqydFcH1m6CCHBGDZrlFuAA3KqXFL46p6xKqd9 CYygbHJDRto1ektIRmLhJsOFAXHJVEk2HCkaKXB7LLAmtkZL2hGCDEk97d3AkUisBnGd NK17IUqKk3xKBFexkYgshqCQc6IH/w3aOnjPDcn0pCHZkhYJAdMiW7ld/mEbyyRY4srG q64fyZtgkktsPp06mFU2qaO6f66oPARfjaNhunLWyojH8kTwP0gVzEqvZYxgDtTdnAFj 5LJg==
Received: by 10.14.178.72 with SMTP id e48mr15361228eem.1.1347920266425; Mon, 17 Sep 2012 15:17:46 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id y1sm31167188eel.0.2012.09.17.15.17.45 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 15:17:45 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5057A188.9080404@gnutls.org>
Date: Tue, 18 Sep 2012 00:17:44 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: Adam Langley <agl@google.com>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org> <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com>
In-Reply-To: <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 22:17:48 -0000

On 09/17/2012 11:33 PM, Adam Langley wrote:

>> I'm curious, how would a stateless compression scheme work?  Compress
>> each record separately?  Is that enough to fix this?
> (We're still keeping quiet about the details of this attack at the
> request of the researchers.)


I got the same request by the researcher, but I am unable to
understand/follow it, when at the same time the fact of the attack is
leaked at all the online technology forums.

> A per-record compression scheme could be implemented in a backward
> compatible fashion with zlib, but is insufficient to stop the attack.


I suppose you mean the Z_FULL_FLUSH? Why is it insufficient?

regards,
Nikos

From n.mavrogiannopoulos@gmail.com  Mon Sep 17 15:19:27 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5121F8468 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8mzvZYxlDWk for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:19:26 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 698F421F8628 for <tls@ietf.org>; Mon, 17 Sep 2012 15:19:26 -0700 (PDT)
Received: by eaai11 with SMTP id i11so2582061eaa.31 for <tls@ietf.org>; Mon, 17 Sep 2012 15:19:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=TRs7g9+igXfsnrSzY3Uz35ohcGkona+FX44TI+8OOic=; b=hUsbGiuoVMZymtRPOMOU2yd4fVnVud1343uVGYtJ1uRqEs3se2KPHyqdb+0K3z4uIN Jbd6f2/xOSJKiwbsqj9nV7GKic7/WcNwooJo1FuM+BvLoZ9IMITfKXNSLDvMYqJgRgrG Ni/mZfH4UH8sgCckwAyKLOjSLo+nYd/KVEDyCI7E5MciV4mBMg+t1EdWEFqpqZPt9R/t +MZDBszlVdLkJhC2fuPln/83SA2V0ZFuIPD6WxQ3aLVV45oIvdEJkzkh/cC6h2Il+Bvr wR+/Zc6wiase3hIzAwd8GIjtp4XkQIB/Hp1CcMKChK5T3QDmDMhrHfB24cFoC3LkvRES eVlg==
Received: by 10.14.184.134 with SMTP id s6mr14971097eem.46.1347920365653; Mon, 17 Sep 2012 15:19:25 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id v3sm31116837eep.10.2012.09.17.15.19.24 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 15:19:24 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5057A1EC.5080303@gnutls.org>
Date: Tue, 18 Sep 2012 00:19:24 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org>
In-Reply-To: <87d31knxsw.fsf@latte.josefsson.org>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 22:19:27 -0000

On 09/17/2012 11:29 PM, Simon Josefsson wrote:


>> and I plan to add a stateless compression mode (which violates RFC3749).
>> Any other ideas?
> I'm curious, how would a stateless compression scheme work?  Compress
> each record separately?  Is that enough to fix this?  I'm thinking some
> applications might concatenate data from different origins into the same
> TLS record anyway.


Indeed, but an application such as a VPN could arrange so that data from
different sources are stored in different records (and actually I had
the VPN application in mind rather than HTTPS for that).

regards,
Nikos

From agl@google.com  Mon Sep 17 15:31:20 2012
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6357921E8097 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rKfxMQj+NnB for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:31:20 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5F5921E8096 for <tls@ietf.org>; Mon, 17 Sep 2012 15:31:19 -0700 (PDT)
Received: by iec9 with SMTP id 9so2223120iec.31 for <tls@ietf.org>; Mon, 17 Sep 2012 15:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Odr6CNy4nSn8mFmR989zpJbwKyBl0dU8TGEy/OSC6tA=; b=deGq4z4w8AdxljIa1e5VpAdJdbw3wG13UBRVJhNt8oKFZJriz0cfI+oROBRM0st2Uu Na3RUtivfPmChrVIWm6/xBPGhuXYfedUKDJilU8+j6dlIkDV5iD3yyFF87OXRb84f6Ig XiIQaU8uso6WI8UMJQgDqvFjn5piC7PkASM8imkReuwVFShXaT3Fdrt9khzMlaqxYHY1 EdMjfgNzySruASIb24eHF3YKCJmZzZAr0FiNo5zAgb0a+f2s22M+OtY/MHIXrQWEjiXW /voCjRR/FPaDl07+qXs/iff3n+6Wx+GWpe0+IAB/lRf1EoBL5EfgzZxK4ynf2i9YbggR YoWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Odr6CNy4nSn8mFmR989zpJbwKyBl0dU8TGEy/OSC6tA=; b=UbvyYnmRUjasfMvu07CJkwxoWFPLjwAaxCwlH6KPWqgxGduigzoOZZ9N/Z5hLgDxYO JRh7cV8TgNOSyqdr2tmcRxJ1QRQxHpqW+ISka2nlECJ2hm/AXWC7/RcVf3OBIn+wsest LBsZmooimxQ/mnwlFS/w/7cLUIPJI+JtysLkXwy2fMXIwvDfCFY0DEPLU//iaeOlohqw TWKqjKa1mPSHq2PRuN3ADECbxw2Cy8qyxDEr+CSNZvz5OlikJXfW+bPS4mSxCfIbXf46 bRdkJU+JmUGDaDruEuDrJlc5qOQ3nNfch9OMilKAW1O33bY8cMf9pPFi/k01j3OGMPjp QoxA==
Received: by 10.43.133.196 with SMTP id hz4mr10277611icc.52.1347921079423; Mon, 17 Sep 2012 15:31:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.133.196 with SMTP id hz4mr10277606icc.52.1347921079329; Mon, 17 Sep 2012 15:31:19 -0700 (PDT)
Received: by 10.231.224.84 with HTTP; Mon, 17 Sep 2012 15:31:19 -0700 (PDT)
In-Reply-To: <5057A188.9080404@gnutls.org>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org> <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com> <5057A188.9080404@gnutls.org>
Date: Mon, 17 Sep 2012 18:31:19 -0400
Message-ID: <CAL9PXLx-CSi8bDTmjwnGH2QRQWvUiTSv_aFpyc9K86VoaubStg@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQk32rlLyR+1KOoBKQIqRMoo8C5N/7UokbhJPcUmG1mnbjxdUxvrLXceEfcJs/qO8Mkctlg489Bv3Rb5/BkxfeRx3L68or+gT8AE8INzuecUyXXv2G8tUpeqwjLuJMYFBNrORSkUi41MWhMpENBOHwdqKIgLy3pIQ3dd3ZMK4NmXyyYEXGPMMAH9KU5KreoSTL2vFMDn
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 22:31:20 -0000

On Mon, Sep 17, 2012 at 6:17 PM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> I suppose you mean the Z_FULL_FLUSH? Why is it insufficient?

Because, within each record, an HTTP client is including attacker
controlled data (i.e. the path) and sensitive data (i.e. a cookie).

By compressing all that together, the resulting length reveals some
information about the sensitive data. By repeating with many queries
where the sensitive data is the same (as it would be for cookies), the
sensitive data leaks.

In fact, I think a Z_FULL_FLUSH would make the attack easier because
the attacker no longer has to worry about the previous record being in
the compression window.


Cheers

AGL

From n.mavrogiannopoulos@gmail.com  Mon Sep 17 15:42:22 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047A021E808C for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnYMBRiPYpM4 for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 15:42:21 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45CF221E8063 for <tls@ietf.org>; Mon, 17 Sep 2012 15:42:21 -0700 (PDT)
Received: by eaai11 with SMTP id i11so2585699eaa.31 for <tls@ietf.org>; Mon, 17 Sep 2012 15:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=7k4PSS/K5rASmNgt4FA/qliwo9hgTiJrfc5H2R8civc=; b=sw4HHRRYUFi4fgPhKwitqkt0TYy8+R3UbDlT0ZaoiGby1gLsKKzXbHboNHXxQVnbEq yXhUGCeD5ljrjWxJaqkk7mUohSaf8C9cGTGGyNcB1VzA2xuUJPaV5O/6Cuz4pZ5geZjK K8NApypYTIP/WXRX+6LyZDR+qKSuQa1YiwB3ebdw5P/iHUGVYEBjC72iOoXhCWko6rhe 6fgYuYcN/8GaAXKtAEOtUT9UBrzFt6Hh2rmkYdBOuexz8yITVX0eJXrsAsXrMa7ML9il vlgTEWLqEg+Kv5PcfZehv0dO734dlw5SbUZ3aDO6r/A6YFz0uiZbm+eNzf9u7JAiye3A UjnQ==
Received: by 10.14.212.72 with SMTP id x48mr15079478eeo.40.1347921740476; Mon, 17 Sep 2012 15:42:20 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id l42sm31273299eep.1.2012.09.17.15.42.19 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 15:42:19 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5057A746.2030200@gnutls.org>
Date: Tue, 18 Sep 2012 00:42:14 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: Adam Langley <agl@google.com>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org> <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com> <5057A188.9080404@gnutls.org> <CAL9PXLx-CSi8bDTmjwnGH2QRQWvUiTSv_aFpyc9K86VoaubStg@mail.gmail.com>
In-Reply-To: <CAL9PXLx-CSi8bDTmjwnGH2QRQWvUiTSv_aFpyc9K86VoaubStg@mail.gmail.com>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 22:42:22 -0000

On 09/18/2012 12:31 AM, Adam Langley wrote:

>> I suppose you mean the Z_FULL_FLUSH? Why is it insufficient?
> Because, within each record, an HTTP client is including attacker
> controlled data (i.e. the path) and sensitive data (i.e. a cookie).
> By compressing all that together, the resulting length reveals some
> information about the sensitive data. By repeating with many queries
> where the sensitive data is the same (as it would be for cookies), the
> sensitive data leaks.

I wasn't clear here. The idea is to use Z_FULL_FLUSH with the data split
in independent records. Indeed in HTTPS may not be easy to split
attacker-controlled data from other data, but I had a VPN case in mind,
where you want to separate the traffic of different users.

Nevertheless compression in TLS, or better compression before encryption
seems quite flawed in a communication channel. Maybe it is better to
disable compression altogether and wait for a compression algorithm that
may be suited for a communication scenario where the adversary controls
parts of the data.

regards,
Nikos

From agl@google.com  Mon Sep 17 16:09:05 2012
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE64D21E808C for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 16:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1d2KRS0aPJk for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 16:09:04 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6297321E8063 for <tls@ietf.org>; Mon, 17 Sep 2012 16:09:04 -0700 (PDT)
Received: by iabz21 with SMTP id z21so6288344iab.31 for <tls@ietf.org>; Mon, 17 Sep 2012 16:09:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=ST+Kjs+jBblXwNEYZispZol1X5a6s55wIkEtH0/nGCQ=; b=MDjgx2dU44JKxhhp7ai0QSb1wrLj1BrADMZGy+3dz6c+2DvsRyPXVeU0TGeIPlrHrR d36YTYmNsvunCHHuI4RJ3A8sg3uXNWtEN51CJLm5wOBfG/OkfE3WvcREC/6ZWC7Wpy+J pUR+6zLDeQpKGRx/DNGyqkrW+iZ+Ozr7HlG+BNhAe419G2Q5/r1HTvXP3SrnFgUhRH4r NygZd7Yf4P9rARDGdalTr9RJ7drzW+T5Nh+ip2hIKxltzZWo1d/vKo1eJlxfqAFBkDXJ 6QJHX58Uyko5VWzgnq8GyUy3W0hJlRRed7REAfGbg/GmnX6dOEcQvN/gRmoocF3hAF0E OpgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ST+Kjs+jBblXwNEYZispZol1X5a6s55wIkEtH0/nGCQ=; b=OAADG+CZnpzYa2y9fTe3TdcUE3dnFVev14n3apnoQ4rJ4KkyPbuZomwxH3Pr3wqf7m OpJW65f2CzgVwhOx6N1U6i9muCWOEd08SrlrCBCu/KS+GTyZq+WrWQDkCqfEwU8KNvSa LwH/kzYCN+QZwYIICaZ0dKIdzR+YhErdbjm/S50NfvXZf82gePInMgcMeP1TXZLSNzg6 AOmTnP4ALFWqdbZNalcEmtndffXtx5R0R5O3BMnVTB3U3rqH9khcu/RPMwoKkxClwvBy zdAzzjzOiItTN/08ovjWhRx+yZ/1l6EHWOa2F5B9dS3jrPsRhg9GiMdLDz0mABZplr1e aEWQ==
Received: by 10.50.140.74 with SMTP id re10mr8490977igb.52.1347923343801; Mon, 17 Sep 2012 16:09:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.140.74 with SMTP id re10mr8490968igb.52.1347923343722; Mon, 17 Sep 2012 16:09:03 -0700 (PDT)
Received: by 10.231.224.84 with HTTP; Mon, 17 Sep 2012 16:09:03 -0700 (PDT)
In-Reply-To: <5057A746.2030200@gnutls.org>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org> <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com> <5057A188.9080404@gnutls.org> <CAL9PXLx-CSi8bDTmjwnGH2QRQWvUiTSv_aFpyc9K86VoaubStg@mail.gmail.com> <5057A746.2030200@gnutls.org>
Date: Mon, 17 Sep 2012 19:09:03 -0400
Message-ID: <CAL9PXLzQdZd3PicnbiOHLwjCT4OKe375MZZx1xM_7j6QYX0oDA@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQndj+oqJIhsGajotAgiDYN5YrWAcm9mA9CdyulHj/WrXI2BKDgtd1DWGRvqkbs5KCrjBk9avOgEsvPbZVVT6guASN3Y/q31fmPFF3uAswoHWba6ivUzSuvDp7/1/BOrV4fIphumRIuyS5VHFUa6E6ZIbk8Yfz1LM2L9Nvy3hf1lv16LY3jf7oWobOPXVs+mVF3e1SxB
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Mon, 17 Sep 2012 23:09:05 -0000

On Mon, Sep 17, 2012 at 6:42 PM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> I wasn't clear here. The idea is to use Z_FULL_FLUSH with the data split
> in independent records. Indeed in HTTPS may not be easy to split
> attacker-controlled data from other data, but I had a VPN case in mind,
> where you want to separate the traffic of different users.

Ah, if you can compress the different classes of data separately, then
certainly that'll be sufficient. In the VPN case you have an easy way
to distinguish classes of data but, as you point that, that's
generally difficult, at least with existing APIs.


Cheers

AGL

From mrex@sap.com  Mon Sep 17 16:35:25 2012
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07B321E809C for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 16:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Level: 
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njgn9x8HBser for <tls@ietfa.amsl.com>; Mon, 17 Sep 2012 16:35:25 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CD79321E808C for <tls@ietf.org>; Mon, 17 Sep 2012 16:35:24 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q8HNZGdM007977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Sep 2012 01:35:16 +0200 (MEST)
In-Reply-To: <5057A746.2030200@gnutls.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Tue, 18 Sep 2012 01:35:16 +0200 (CEST)
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: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 17 Sep 2012 23:35:25 -0000

Nikos Mavrogiannopoulos wrote:
>
> Adam Langley wrote:
> 
> >> I suppose you mean the Z_FULL_FLUSH? Why is it insufficient?
> > Because, within each record, an HTTP client is including attacker
> > controlled data (i.e. the path) and sensitive data (i.e. a cookie).
> > By compressing all that together, the resulting length reveals some
> > information about the sensitive data. By repeating with many queries
> > where the sensitive data is the same (as it would be for cookies), the
> > sensitive data leaks.
> 
> I wasn't clear here. The idea is to use Z_FULL_FLUSH with the data split
> in independent records. Indeed in HTTPS may not be easy to split
> attacker-controlled data from other data, but I had a VPN case in mind,
> where you want to separate the traffic of different users.

Using a single TLS connection state to process data from different users
is a serious fallacy of the application on top of TLS.  Using seperate
TLS connection states for each user (and multiplexing the result over
a single TCP connection) would entirely prevent that problem.
Creating only the initial connection states through full handshake
and all others through abbreviated handshakes (aka session resume)
would be OK, since the traffic keys are distinct for different
connection states.

Admittedly, this might require a backwards-incompatible change to
existing SSL-VPN protocol designs.  Has anyone ever proposed that
all hosts in a subnet should be using the same IPsec traffic keys?
I wonder how/why such a flawed design got used for SSL-VPNs.


> 
> Nevertheless compression in TLS, or better compression before encryption
> seems quite flawed in a communication channel.

Compression after encryption seems quite a waste (since one of the
criteria for good encryption algorithms is that they make the
redundancy / repeating patterns of data disappear which existing
compression algorithms vitally need to achive any compression.


>
> Maybe it is better to disable compression altogether

or never had it implemented from the beginning :)


>
>                                                      and wait for a
> compression algorithm that may be suited for a communication scenario
> where the adversary controls parts of the data.

The compression algorithm is not the problem here.
The mixing of attacker supplied data an assumed confidential
data is the real problem.

If you ever have to do this, then you MUST NOT provide an oracle
for the attacker that he can use to repeatedly guess about
characteristics of the very same confidential data.


Think about is, guessing SSL cookies (what BEAST did and CRIME does)
is actually pretty lame.  The real problem is, that a browser will
happily execute attacker-supplied active content and insert a static
SSL-cookie or static session id that provides a disclosing
authentication across requests.  Even with compression disable,
TLSv1.2 and no possibility for the attacker to observe (let alone MitM)
the network traffic, the attacker can simply ask the browser to
perform whatever fraudulent POST the attacker wants performed, and
the browser will happily perform it.  THAT is the real problem,
and fixing that problem will require serious reengineering of
how request authentication is performed on the Web.


-Martin

From fweimer@redhat.com  Tue Sep 18 00:26:37 2012
Return-Path: <fweimer@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3882F21F85C7 for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 00:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugB-dfbxiAEb for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 00:26:36 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 611E021F8557 for <tls@ietf.org>; Tue, 18 Sep 2012 00:26:36 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8I7QWJF009888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Sep 2012 03:26:32 -0400
Received: from fweimer.str.redhat.com (dhcp-5-241.str.redhat.com [10.32.5.241]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q8I7QTMV003643 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 03:26:30 -0400
Message-ID: <50582225.6060503@redhat.com>
Date: Tue, 18 Sep 2012 09:26:29 +0200
From: Florian Weimer <fweimer@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Adam Langley <agl@google.com>
References: <505792AB.5000207@gnutls.org> <87d31knxsw.fsf@latte.josefsson.org> <CAL9PXLzyf3DkUHfKEu2+m7mHJsT23aL_AFP3G+pSU8j=rGikrw@mail.gmail.com> <5057A188.9080404@gnutls.org> <CAL9PXLx-CSi8bDTmjwnGH2QRQWvUiTSv_aFpyc9K86VoaubStg@mail.gmail.com> <5057A746.2030200@gnutls.org> <CAL9PXLzQdZd3PicnbiOHLwjCT4OKe375MZZx1xM_7j6QYX0oDA@mail.gmail.com>
In-Reply-To: <CAL9PXLzQdZd3PicnbiOHLwjCT4OKe375MZZx1xM_7j6QYX0oDA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 18 Sep 2012 07:26:37 -0000

On 09/18/2012 01:09 AM, Adam Langley wrote:
> On Mon, Sep 17, 2012 at 6:42 PM, Nikos Mavrogiannopoulos
> <nmav@gnutls.org> wrote:
>> I wasn't clear here. The idea is to use Z_FULL_FLUSH with the data split
>> in independent records. Indeed in HTTPS may not be easy to split
>> attacker-controlled data from other data, but I had a VPN case in mind,
>> where you want to separate the traffic of different users.
>
> Ah, if you can compress the different classes of data separately, then
> certainly that'll be sufficient.

Depending on the application, quite a bit of data can still leak, 
particularly if you can determine the plaintext length and thus infer 
the compression ratio.  For example, it's been demonstrated that you can 
detected a wide range of phonemes in compressed and encrypted voice traffic.

-- 
Florian Weimer / Red Hat Product Security Team

From n.mavrogiannopoulos@gmail.com  Tue Sep 18 02:44:07 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5FF21F8790 for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 02:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGl-X2HRo0uW for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 02:44:07 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02BBA21F877C for <tls@ietf.org>; Tue, 18 Sep 2012 02:44:06 -0700 (PDT)
Received: by eekb45 with SMTP id b45so3898787eek.31 for <tls@ietf.org>; Tue, 18 Sep 2012 02:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=IO6oU3nabeMUvSguOIiBvzoOMM4JikbVCYiTufLt0Dc=; b=AdHQUAHA8iCnFCS97bd42Y02ljlE/EEEXM5lgCFBs7Ny52odCm3+Pc8WrqCw6RwKks vs4CQJrItLyrCcoCNTxNBLdD/oCzpCeLGJ3r2hpiBKDANqKVnh0nQphib7PWZ217kW+v peIn55GwCMI9PWQk3P0hgW5P4PSnNR1telYQdxKnY+1mBf+mj9Sg16H3VJOpQTQsrGlO 17yRhx7FX1l+xLAIk/1b4xbdEbYvLptJnLNHzfivYgIREDvTpaeV1m3xWzAj5BJ57qla bU3Ze6QTHkhOCPo80NpuoVl0vDw3Oj3FSIGVUSJccggm8rsKhDQ+F0H6Tp2BcTK69EoA WrZQ==
Received: by 10.14.215.193 with SMTP id e41mr16670327eep.44.1347961445988; Tue, 18 Sep 2012 02:44:05 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id e42sm34785997eem.8.2012.09.18.02.44.03 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 02:44:04 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5058425E.6090903@gnutls.org>
Date: Tue, 18 Sep 2012 11:43:58 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: mrex@sap.com
References: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp>
In-Reply-To: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 18 Sep 2012 09:44:07 -0000

On 09/18/2012 01:35 AM, Martin Rex wrote:


> Using a single TLS connection state to process data from different users
> is a serious fallacy of the application on top of TLS.  Using seperate
> TLS connection states for each user (and multiplexing the result over
> a single TCP connection) would entirely prevent that problem.
> Creating only the initial connection states through full handshake
> and all others through abbreviated handshakes (aka session resume)
> would be OK, since the traffic keys are distinct for different
> connection states.


I do not share this view. There is really no other way. The same claim
can be repeated for mixing separate application data into the same user
tunnel, and then for mixing application input with user input in the
same application tunnel and so on. Once you have a tunnel, you must make
sure the tunnel offers its promise (confidentiality) irrespective of the
data that pass from it.

>> Nevertheless compression in TLS, or better compression before encryption

>> seems quite flawed in a communication channel.
> Compression after encryption seems quite a waste 


I made no point on compression after encryption.

>>                                                      and wait for a
>> compression algorithm that may be suited for a communication scenario
>> where the adversary controls parts of the data.
> The compression algorithm is not the problem here.
> The mixing of attacker supplied data an assumed confidential
> data is the real problem.


The problem is that there no confidential and non-confidential data for
TLS. TLS operates in an abstract way under some application protocol. It
was designed in a way to operate under any application protocol no
matter how it arranged its confidential or non-confidential data.

This proved to be more difficult than anticipated with the CBC attacks
and now the compression ones.

> If you ever have to do this, then you MUST NOT provide an oracle
> for the attacker that he can use to repeatedly guess about
> characteristics of the very same confidential data.


This is a concern, that unfortunately TLS can do very little. The oracle
is typically provided by the upper layers and TLS should protect
(ideally) without having any knowledge of their operation.

regards,
Nikos

From richih.mailinglist@gmail.com  Tue Sep 18 05:55:51 2012
Return-Path: <richih.mailinglist@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8A21F869A for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 05:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8cN34egVm7R for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 05:55:51 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D831921F8691 for <tls@ietf.org>; Tue, 18 Sep 2012 05:55:50 -0700 (PDT)
Received: by lbky2 with SMTP id y2so5323201lbk.31 for <tls@ietf.org>; Tue, 18 Sep 2012 05:55:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tHWGJ7xWGnFRKAi47Zsnf3LfcCvAj1ZkUB5zM7xx1H8=; b=EwL+q3eh3V+cTetyGL+K8ibuzq7AlUqmQTHlixpADw3xfYtMgRb16M+OIkW4Ovx+Ah 9s/wR2f7dGLAwSXgrdb1Y3oWKKoEc6AXfSj6BWD2rMKIpw3cwzinmNa5uilVZQzT1X96 YFkp3TOo0qMoaLM5+VawJDkHnvFU77NgN6X5sWBqQIcRlWATn5Fczv5jnD68SDsz1AWE o1GE0XLlW42gJ0YS8HCmTUDWKEhYystGsgWVeJ2+zIwvWStX6txDclUG0AEeTQPsuF/T ZynAUubotkeHgMiWY7Wnx8BaI19i1EPBmkvFYNoWzdpOamBW6Zbn1FIfkCgwRZNz7DV5 mc1Q==
Received: by 10.112.9.68 with SMTP id x4mr208362lba.46.1347972949453; Tue, 18 Sep 2012 05:55:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.42.198 with HTTP; Tue, 18 Sep 2012 05:55:29 -0700 (PDT)
In-Reply-To: <5058425E.6090903@gnutls.org>
References: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp> <5058425E.6090903@gnutls.org>
From: Richard Hartmann <richih.mailinglist@gmail.com>
Date: Tue, 18 Sep 2012 14:55:29 +0200
Message-ID: <CAD77+gQHcE1j0QAtusLh6KWAkB6Sb=4KgBuVtEdcFQ3HTL04OQ@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=UTF-8
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 18 Sep 2012 12:55:51 -0000

On Tue, Sep 18, 2012 at 11:43 AM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:

> I do not share this view. [...]
> Once you have a tunnel, you must make
> sure the tunnel offers its promise (confidentiality) irrespective of the
> data that pass from it.

Adding more layers of security is (almost always) a Good Thing if
performance and other metrics are not impacted.

That being said, I agree that a tunnel should be secure no matter what
you send through it.


> The problem is that there no confidential and non-confidential data for
> TLS. TLS operates in an abstract way under some application protocol. It
> was designed in a way to operate under any application protocol no
> matter how it arranged its confidential or non-confidential data.
[...]
> This is a concern, that unfortunately TLS can do very little. The oracle
> is typically provided by the upper layers and TLS should protect
> (ideally) without having any knowledge of their operation.

As it has to be. Everything else would be a clear violation of layering.


-- 
Richard

From simon@josefsson.org  Tue Sep 18 06:21:05 2012
Return-Path: <simon@josefsson.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF4D21F87D5 for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 06:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.801
X-Spam-Level: 
X-Spam-Status: No, score=-99.801 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+brvhL1AxGo for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 06:21:05 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6821F875D for <tls@ietf.org>; Tue, 18 Sep 2012 06:21:03 -0700 (PDT)
Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q8IDKoPC017166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Sep 2012 15:20:52 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Richard Hartmann <richih.mailinglist@gmail.com>
References: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp> <5058425E.6090903@gnutls.org> <CAD77+gQHcE1j0QAtusLh6KWAkB6Sb=4KgBuVtEdcFQ3HTL04OQ@mail.gmail.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120918:nmav@gnutls.org::L6zJZ0vwPLc2tgmn:2cDd
X-Hashcash: 1:22:120918:richih.mailinglist@gmail.com::8Wg537a70hEPC61r:CQij
X-Hashcash: 1:22:120918:tls@ietf.org::2WRP7MPZuPtD2w6R:F4I/
X-Hashcash: 1:22:120918:mrex@sap.com::xzX5xcqDlXk6/vZU:K2Fh
Date: Tue, 18 Sep 2012 15:20:49 +0200
In-Reply-To: <CAD77+gQHcE1j0QAtusLh6KWAkB6Sb=4KgBuVtEdcFQ3HTL04OQ@mail.gmail.com> (Richard Hartmann's message of "Tue, 18 Sep 2012 14:55:29 +0200")
Message-ID: <874nmvjwlq.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 18 Sep 2012 13:21:05 -0000

Richard Hartmann <richih.mailinglist@gmail.com> writes:

> That being said, I agree that a tunnel should be secure no matter what
> you send through it.

Secure against what?  Some length and timing information of plaintext
data will always be revealed with the current TLS design.

There are always-on systems out there that transmit data at a constant
rate and of constant size, with payload interleaved into the otherwise
random data, but from a bandwidth utilization and Internet scalability
point of view those models are fairly unappealing.

/Simon

From richih.mailinglist@gmail.com  Tue Sep 18 06:32:47 2012
Return-Path: <richih.mailinglist@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B3A21F8604 for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 06:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NdXU9dU4a5d for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 06:32:47 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA30E21F85FC for <tls@ietf.org>; Tue, 18 Sep 2012 06:32:46 -0700 (PDT)
Received: by lahm15 with SMTP id m15so5288250lah.31 for <tls@ietf.org>; Tue, 18 Sep 2012 06:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ejP6YEYgFZAGS/3X+ztI/4izU3hvymjLdQWXUcz+7rQ=; b=B+BTURT2qhT/ej2zxX9jJ+ojm5r1Ja4QbVM8bac78SQ+ZozAa/P488/BlJHekgdHF9 03E5+Sdpn8slyLa4CBbywPaSEZI/zi1mARI1yzw8CiciQpE2lOkv9obx4XP/QOOBZjg9 W4ffmoiS519uEpejMtFhsQm5xMekqkFbB0zYD66VJZEs0J3/7E3gTYpObvJCo3czJRVE uAgs6DQtCRhe+ggE5+cRV9MPwSqFvgsD2g+6hLcYVF++EORyYQuABuze5ofAn+hpw1YK QBxOclPKYtDlBYGiZmSYfraAiM25V2ycHec9ZYUvqRsyoSYJ0Or1RPaznmaG2iTaBeyR 4GJw==
Received: by 10.112.49.197 with SMTP id w5mr255852lbn.3.1347975164675; Tue, 18 Sep 2012 06:32:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.42.198 with HTTP; Tue, 18 Sep 2012 06:32:24 -0700 (PDT)
In-Reply-To: <874nmvjwlq.fsf@latte.josefsson.org>
References: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp> <5058425E.6090903@gnutls.org> <CAD77+gQHcE1j0QAtusLh6KWAkB6Sb=4KgBuVtEdcFQ3HTL04OQ@mail.gmail.com> <874nmvjwlq.fsf@latte.josefsson.org>
From: Richard Hartmann <richih.mailinglist@gmail.com>
Date: Tue, 18 Sep 2012 15:32:24 +0200
Message-ID: <CAD77+gSNK6KdFTPK6hfQQnj_CxgCD=rkGHkK=9JGnCfB9QoF1A@mail.gmail.com>
To: Simon Josefsson <simon@josefsson.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 18 Sep 2012 13:32:48 -0000

On Tue, Sep 18, 2012 at 3:20 PM, Simon Josefsson <simon@josefsson.org> wrote:

> Secure against what?  Some length and timing information of plaintext
> data will always be revealed with the current TLS design.

Fair point, I should have specified that.

Let's not descend into obvious assumptions, but you are correct in
calling me out on not being specific; thanks


-- 
Richard

From turners@ieca.com  Tue Sep 18 09:35:16 2012
Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016C721F862A for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 09:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.103
X-Spam-Level: 
X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdsNE0nuzJeR for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 09:35:15 -0700 (PDT)
Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.39.7]) by ietfa.amsl.com (Postfix) with ESMTP id F133721F8622 for <tls@ietf.org>; Tue, 18 Sep 2012 09:35:14 -0700 (PDT)
Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 650B227E09DF4; Tue, 18 Sep 2012 11:35:14 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 57B1F27E09DB4 for <tls@ietf.org>; Tue, 18 Sep 2012 11:35:14 -0500 (CDT)
Received: from [108.18.174.220] (port=55774 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <turners@ieca.com>) id 1TE0lW-0003OV-0u for tls@ietf.org; Tue, 18 Sep 2012 11:35:14 -0500
Message-ID: <5058A2C1.5000602@ieca.com>
Date: Tue, 18 Sep 2012 12:35:13 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: tls@ietf.org
References: <20120918161313.20374.9674.idtracker@ietfa.amsl.com>
In-Reply-To: <20120918161313.20374.9674.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120918161313.20374.9674.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [108.18.174.220]:55774
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 8
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [TLS] Fwd: [secdir] [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)
X-BeenThere: tls@ietf.org
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." <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, 18 Sep 2012 16:35:16 -0000

The http-bis wg recharter ought to be of interest to the TLS WG.

spt

-------- Original Message --------
Subject: [secdir] [new-work] WG Review: Hypertext Transfer Protocol Bis 
(httpbis)
Date: Tue, 18 Sep 2012 09:13:13 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org

The Hypertext Transfer Protocol Bis (httpbis) working group in the
Applications Area of the IETF is undergoing rechartering. The IESG has
not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2012-09-25.

Hypertext Transfer Protocol Bis (httpbis)
------------------------------------------------
Current Status: Active Working Group

Chairs:
   Mark Nottingham <mnot@pobox.com>

Assigned Area Director:
   Barry Leiba <barryleiba@computer.org>

Mailing list
   Address: ietf-http-wg@w3.org
   To Subscribe: ietf-http-wg-request@w3.org
   Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/

Charter of Working Group:

This Working Group is charged with maintaining and developing the "core"
specifications for HTTP.

The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC 2616
as
   the definition of HTTP/1.1 and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document (or set of documents) that specifies HTTP/2.0, an improved
   binding of HTTP's semantics to an underlying transport.

HTTP/1.1
--------

HTTP/1.1 is one of the most successful and widely-used protocols on the
Internet today. However, its specification has several editorial issues.
Additionally, after years of implementation and extension, several
ambiguities
have become evident, impairing interoperability and the ability to easily
implement and use HTTP.

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries,
ABNF)
* Fix editorial problems which have led to misunderstandings of the
   specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented and
   also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated mechanisms
   (e.g., Basic and Digest authentication, cookies, TLS) for common
   applications

It will also incorporate the generic authentication framework from RFC
2617, without obsoleting or updating that specification's definition of
the Basic and Digest schemes.

Finally, it will incorporate relevant portions of RFC 2817 (in
particular, the CONNECT method and advice on the use of Upgrade), so
that that specification can be moved to Historic status.

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

HTTP/2.0
--------

There is emerging implementation experience and interest in a protocol
that
retains the semantics of HTTP without the legacy of HTTP/1.x message
framing and syntax, which have been identified as hampering performance
and
encouraging misuse of the underlying transport.

The Working Group will produce a specification of a new expression of
HTTP's
current semantics in ordered, bi-directional streams. As with HTTP/1.x,
the primary target transport is TCP, but it should be possible to use
other transports.

Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point;
proposals are to be expressed in terms of changes to that document. Note
that
consensus is required both for changes to the document and anything that
remains in the document.

As part of that work, the following issues are explicitly called out for
discussion:
* A negotiation mechanism that is capable of not only choosing between
   HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other
   transports (for example).
* Header compression (which may encompass header encoding or
tokenisation)
* Server push (which may encompass pull or other techniques)

It is expected that HTTP/2.0 will:
* Substantially and measurably improve end-user perceived latency in most
   cases, over HTTP/1.1 using TCP.
* Address the "head of line blocking" problem in HTTP.
* Not require multiple connections to a server to enable parallelism,
thus
   improving its use of TCP, especially regarding congestion control.
* Retain the semantics of HTTP/1.1, leveraging existing documentation
(see
   above), including (but not limited to) HTTP methods, status codes,
URIs, and
   where appropriate, header fields.
* Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in
   intermediaries (both 2->1 and 1->2).
* Clearly identify any new extensibility points and policy for their
   appropriate use.

The resulting specification(s) are expected to meet these goals for
common
existing deployments of HTTP; in particular, Web browsing (desktop and
mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of
scales), and
intermediation (by proxies, corporate firewalls, "reverse" proxies and
Content
Delivery Networks). Likewise, current and future semantic extensions to
HTTP/1.x (e.g., headers, methods, status codes, cache directives) should
be
supported in the new protocol.

Note that this does not include uses of HTTP where non-specified
behaviours
are relied upon (e.g., connection state such as timeouts or client
affinity,
and "interception" proxies); these uses may or may not be enabled by the
final
product.

Explicitly out-of-scope items include:
* Specifying the use of alternate transport-layer protocols. Note that it

   is expected that the Working Group will work with the TLS working group
   to define how the protocol is used with the TLS Protocol.
* Specifying how the HTTP protocol is to be used or presented in a
specific
   use case (e.g., in Web browsers).

The Working Group will coordinate this item with:
* The TLS Working Group, regarding use of TLS.
* The Transport Area, regarding impact on and interaction with transport
   protocols.
* The HYBI Working Group, regarding the possible future extension of
HTTP/2.0
   to carry WebSockets semantics.

The Working Group will give priority to HTTP/1.1 work until that work is
complete.

Other HTTP-Related Work
-----------------------

The Working Group may define additional extensions to HTTP as work items,
provided that:
* The Working Group Chairs judge that there is consensus to take on the
item
   and believe that it will not interfere with the work described above,
and
* The Area Directors approve the addition and add corresponding
milestones.

Additionally, the Working Group will not start work on any extensions
that
are specific to HTTP/2.0 until that work is completed.


Goals and Milestones

Done	First HTTP/1.1 Revision Internet Draft
Done	First HTTP Security Properties Internet Draft
Done	Call for Proposals for HTTP/2.0
Sep 2012	Working Group Last Call for HTTP/1.1 Revision
Oct 2012	Working Group Last Call for HTTP Security Properties
Oct 2012	First WG draft of HTTP/2.0, based upon
draft-mbelshe-httpbis-spdy-00
Nov 2012	Submit HTTP/1.1 Revision to IESG for consideration as a Proposed
Standard
Nov 2012	Submit HTTP Security Properties to IESG for consideration as
Informational RFC
Apr 2014	Working Group Last call for HTTP/2.0
Nov 2014	Submit HTTP/2.0 to IESG for consideration as a Proposed Standard

Milestones:
   Done     - First HTTP/1.1 Revision Internet Draft
   Done     - First HTTP Security Properties Internet Draft
   Mar 2012 - Working Group Last Call for HTTP/1.1 Revision
   Mar 2012 - Call for Proposals for HTTP/2.0
   Jun 2012 - Working Group Last Call for HTTP Security Properties
   Jul 2012 - Submit HTTP/1.1 Revision to IESG for consideration as a
Proposed Standard
   Jul 2012 - Submit HTTP Security Properties to IESG for consideration as
Informational RFC
   Aug 2012 - Re-charter to work on HTTP/2.0
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview




From geoffk@geoffk.org  Tue Sep 18 17:46:38 2012
Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0B211E80C5 for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 17:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fArxu55yY6X for <tls@ietfa.amsl.com>; Tue, 18 Sep 2012 17:46:36 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id D790A11E80A5 for <tls@ietf.org>; Tue, 18 Sep 2012 17:46:36 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 789B133D064; Wed, 19 Sep 2012 00:46:33 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Simon Josefsson <simon@josefsson.org>
References: <20120917233516.89DAB1A22F@ld9781.wdf.sap.corp> <5058425E.6090903@gnutls.org> <CAD77+gQHcE1j0QAtusLh6KWAkB6Sb=4KgBuVtEdcFQ3HTL04OQ@mail.gmail.com> <874nmvjwlq.fsf@latte.josefsson.org>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 18 Sep 2012 17:46:33 -0700
In-Reply-To: <874nmvjwlq.fsf@latte.josefsson.org>
Message-ID: <m2d31ix2ja.fsf@localhost.localdomain>
Lines: 16
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 19 Sep 2012 00:46:39 -0000

Simon Josefsson <simon@josefsson.org> writes:

> Richard Hartmann <richih.mailinglist@gmail.com> writes:
> 
> > That being said, I agree that a tunnel should be secure no matter what
> > you send through it.
> 
> Secure against what?  Some length and timing information of plaintext
> data will always be revealed with the current TLS design.

This is an acknowledeged flaw in TLS, I don't think it contradicts
Richard's point---this 'should' be fixed, if only we knew how.

Another thing that TLS can't avoid is that it reveals the existence of
the connection.  This is often far more significant than any details of
which data is being transferred.

From mrex@sap.com  Wed Sep 19 08:26:07 2012
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38C621F8669 for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 08:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.296
X-Spam-Level: 
X-Spam-Status: No, score=-9.296 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lquOeFitbro4 for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 08:26:06 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68621F8665 for <tls@ietf.org>; Wed, 19 Sep 2012 08:26:06 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q8JFPt87014862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 17:25:55 +0200 (MEST)
In-Reply-To: <5058425E.6090903@gnutls.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Wed, 19 Sep 2012 17:25:54 +0200 (CEST)
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: <20120919152554.C92901A23C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 19 Sep 2012 15:26:07 -0000

Nikos Mavrogiannopoulos wrote:
>
> Martin Rex wrote:
> > 
> > Using a single TLS connection state to process data from different users
> > is a serious fallacy of the application on top of TLS.  Using seperate
> > TLS connection states for each user (and multiplexing the result over
> > a single TCP connection) would entirely prevent that problem.
> > Creating only the initial connection states through full handshake
> > and all others through abbreviated handshakes (aka session resume)
> > would be OK, since the traffic keys are distinct for different
> > connection states.
> 
> 
> I do not share this view. There is really no other way.

Of course, there is.

> The same claim can be repeated for mixing separate application data
> into the same user tunnel, and then for mixing application input
> with user input in the same application tunnel and so on. Once you
> have a tunnel, you must make sure the tunnel offers its promise
> (confidentiality) irrespective of the data that pass from it.

(Existing SSL/) TLS *is* no such tunnel, and never was.
This is *well* known, obvious and self-evident.

RFC 5246 even spells it out explicitly:

   http://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

   Note in particular that type and length of a record are not protected
   by encryption.  If this information is itself sensitive, application
   designers may wish to take steps (padding, cover traffic) to minimize
   information leakage.


Recall what was described as a characteristic for SSL (and is still present
in current version of TLS) in the 1996 USENIX paper from Wagner and Schneier
"Analysis of the SSL 3.0 protocol".

  http://www.schneier.com/paper-ssl.pdf

  3.1  Confidentiality: eavesdropping

  SSL will provide a lot of known plaintext to the eavesdropper,
  but there seems to be no better alternative; since the encryption
  algorithm is required to be strong against known-plaintext attacks
  anyway, this should not be problematic. 


  What Wagner/Schneier are refering to with this is describe in
  Bruce Schneiers "Applied Cryptography"
  Section 1.1 Terminology, Cryptoanalysis (page 6 in Second Edition)

   2. known-plaintext attack


What the Web-Browser is doing in the BEAST and CRIME attacks, is however
providing to the attacker for free a facility that is vaguely similar to

  4. adaptive-chosen-plaintext attack

What the attacker succeeds in doing is *NOT* breaking of the
encryption (no recovery of encryption keys is performed), but
instead recovery of specific plaintext.


> 
> > If you ever have to do this, then you MUST NOT provide an oracle
> > for the attacker that he can use to repeatedly guess about
> > characteristics of the very same confidential data.
> 
> This is a concern, that unfortunately TLS can do very little. The oracle
> is typically provided by the upper layers and TLS should protect
> (ideally) without having any knowledge of their operation.

Similar to the general rule "attacks only get better", the security
properties of a cryptographic protocol can only be further spoiled
by how applications use a protocols.  So applications MUST NOT be
ignorant in how they employ cryptographic protocols.  Instead,
cryptographic engineering must be used to design how an application
uses a cryptographic protocol, so that the app does not spoil
all of the security properties.


To obtain the tunnel properties/characteristics that you're looking for,
a higher effort would be necessary, and the obvious "known plaintext"
property of existing TLS would have to be removed.


What comes to mind here might be a randomly sized random padding at
the start plus at the end of the plaintext, plus an additional *inner*
encryption with a symmetric stream cipher.  That mostly fixes the
"lots of known plaintext" design property of the regular/outer
symmetric encryption of TLS (it will still not completely hide
plaintext length information, though).


-Martin

From nico@cryptonector.com  Wed Sep 19 09:28:59 2012
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBAB21F8643 for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 09:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.114
X-Spam-Level: 
X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8yehTVHF5XW for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 09:28:58 -0700 (PDT)
Received: from homiemail-a65.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id EA34121F8647 for <tls@ietf.org>; Wed, 19 Sep 2012 09:28:58 -0700 (PDT)
Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 8A3167E406F for <tls@ietf.org>; Wed, 19 Sep 2012 09:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SVGJZXcn78mmXK3fRBje OrXEgYc=; b=Ho6SYY4uvanXd87MPkhShpsnixRuTkiNsbSh9GWJaNgd8c71hDCr tiPrtersxBSh294lhyGbTxzD7elvrKwtNPElzoySiOh4q1yaX695qUdGc9ho6r0u OXhK8TmYP/+C7o01ooG48aFYPl3PhvIiS/lpfUKn1SQ/Y208F7QOV7o=
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 6F8107E4062 for <tls@ietf.org>; Wed, 19 Sep 2012 09:28:58 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so554448pbb.31 for <tls@ietf.org>; Wed, 19 Sep 2012 09:28:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.236.69 with SMTP id us5mr2863843pbc.59.1348072137958; Wed, 19 Sep 2012 09:28:57 -0700 (PDT)
Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 09:28:57 -0700 (PDT)
In-Reply-To: <505792AB.5000207@gnutls.org>
References: <505792AB.5000207@gnutls.org>
Date: Wed, 19 Sep 2012 11:28:57 -0500
Message-ID: <CAK3OfOghqB-csbQkAMpdco0P6uXqLTM06jj9Zn_PGEQ9Du_P8w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 19 Sep 2012 16:28:59 -0000

ISTM that the right place to put compression is at the application
layer.  I.e., in the content encoding.  This being HTTP, using
transfer encoding has to work and it would indeed.  So, no compression
in TLS but compression at the application and/or proxy -> no attack.
We can do this because HTTP apps often already know how to do
compression at the app layer.

Of course, moving responsibility for compression up a layer or two
does nothing with respect to BEAST-like attacks on TLS because we're
not talking about [and no one would seriously propose, I'm sure]
moving responsibility for crypto up a layer or two either.  That said,
we know how to protect against adaptive chosen plaintext attacks, so
that should not be an issue now.

Nico
--

From mrex@sap.com  Wed Sep 19 10:17:58 2012
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13A21F8678 for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 10:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.167
X-Spam-Level: 
X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niVIcWPDdxZI for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 10:17:58 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3521F8643 for <tls@ietf.org>; Wed, 19 Sep 2012 10:17:57 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q8JHHoRc009943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 19:17:50 +0200 (MEST)
In-Reply-To: <CAK3OfOghqB-csbQkAMpdco0P6uXqLTM06jj9Zn_PGEQ9Du_P8w@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Date: Wed, 19 Sep 2012 19:17:49 +0200 (CEST)
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: <20120919171749.EDCA41A23C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 19 Sep 2012 17:17:58 -0000

Nico Williams wrote:
>
> ISTM that the right place to put compression is at the application
> layer.  i.e., in the content encoding.

That does not really solve the problem that the CRIME attack feeds on.
(and I didn't comment on the compression in my last reply either,
 but also did not change the thread subject...)


Compression can easily spoil your confidentialy.  Sometimes completely.
The motivation for using compression is reduction of length of your data.
This can spoil your confidentiality whenever differences in length
are visible to an attacker, and typical compression output is completely
deterministic and predictable for known compression input.

So if the entirey set of possible "answers" to a specific question
compresses to a distinct length, and all these distinct lengths
are recognizable to an attacker, it will not matter how perfect your
encryption algorithm is, there will not be any confidentiality.

For the TLS compression situation, concatenating attacker-supplied
and assumed confidential data before feeding it to a compression
function is already dangerous, because the compression output
will vary depending on the similarities between the attacker-supplied
and the assumed confidential data.  When providing the attacker a
facility to perform an adaptive chosen attack on such a compression
(concatenation of attacker supplied and assumed confidential data),
then you will quickly spoil your entire confidentiality if the
output length of the compression function can be observed by
the attacker.

 
So it doesn't really matter where in the software stack you perform
compression.  The problem occurs whenever attacker-supplied and
assumed confidential data is fed into a compression function, and
differences in the resulting output length can be observed by the
attacker.


The only reliable countermeasure (pad all possible compression outputs to
the exact same length) will usually defeat the purpose of compression.


-Martin

From nico@cryptonector.com  Wed Sep 19 10:40:30 2012
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC721F86B0 for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 10:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level: 
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=-0.133,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2q7Syd2j9vU for <tls@ietfa.amsl.com>; Wed, 19 Sep 2012 10:40:30 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 092C821F86AD for <tls@ietf.org>; Wed, 19 Sep 2012 10:40:30 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id AABBC10049 for <tls@ietf.org>; Wed, 19 Sep 2012 10:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FCiXehYemrRo9eZQR2BX xlb5UF4=; b=JM9ZmSHho+GSpyQXerduQilC7Og4rUNydoUh4sHGumAtwTK3CMmH HZ1IJMDB2QN9EYJrWGGkPjt64ITGo6OUoPgYliXZgAMR9T/d1VfuOvvDBk2MTlvZ /eag0cnBRvrA233ae4bKhnYOXCWigZtSuSS3kNIt6BPggWptl/ysAgA=
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 8EE101001D for <tls@ietf.org>; Wed, 19 Sep 2012 10:40:29 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so691625pbb.31 for <tls@ietf.org>; Wed, 19 Sep 2012 10:40:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.224.73 with SMTP id ra9mr47539pbc.85.1348076429090; Wed, 19 Sep 2012 10:40:29 -0700 (PDT)
Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 10:40:29 -0700 (PDT)
In-Reply-To: <20120919171749.EDCA41A23C@ld9781.wdf.sap.corp>
References: <CAK3OfOghqB-csbQkAMpdco0P6uXqLTM06jj9Zn_PGEQ9Du_P8w@mail.gmail.com> <20120919171749.EDCA41A23C@ld9781.wdf.sap.corp>
Date: Wed, 19 Sep 2012 12:40:29 -0500
Message-ID: <CAK3OfOh4JB2yZ=eo-Vei_zW+mYeARv3X0vL9o+=V5v5T4=DjjQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 19 Sep 2012 17:40:30 -0000

On Wed, Sep 19, 2012 at 12:17 PM, Martin Rex <mrex@sap.com> wrote:
> So it doesn't really matter where in the software stack you perform
> compression.  The problem occurs whenever attacker-supplied and
> assumed confidential data is fed into a compression function, and
> differences in the resulting output length can be observed by the
> attacker.

By doing compression at the application layer we allow the application
to decide which data deserve a higher quality of protection.  Static,
might-as-well-be-public data can be compressed.

Nico
--

From zhou.sujing@zte.com.cn  Thu Sep 20 02:50:48 2012
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB321F8787; Thu, 20 Sep 2012 02:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.254
X-Spam-Level: 
X-Spam-Status: No, score=-96.254 tagged_above=-999 required=5 tests=[AWL=2.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGYGrxeYECwu; Thu, 20 Sep 2012 02:50:48 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6432A21F8782; Thu, 20 Sep 2012 02:50:47 -0700 (PDT)
Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 551311745333492; Thu, 20 Sep 2012 17:42:47 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 10C5E723BD1; Thu, 20 Sep 2012 17:47:06 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q8K9ocTV018117; Thu, 20 Sep 2012 17:50:38 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <CAK3OfOh4JB2yZ=eo-Vei_zW+mYeARv3X0vL9o+=V5v5T4=DjjQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF7AA95AAA.176D463E-ON48257A7F.0035D79A-48257A7F.0036259E@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Thu, 20 Sep 2012 17:50:30 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-20 17:50:35, Serialize complete at 2012-09-20 17:50:35
Content-Type: multipart/alternative; boundary="=_alternative 0036259D48257A7F_="
X-MAIL: mse02.zte.com.cn q8K9ocTV018117
Cc: tls-bounces@ietf.org, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 20 Sep 2012 09:50:48 -0000

This is a multipart message in MIME format.
--=_alternative 0036259D48257A7F_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

dGxzLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTA5LTIwIDAxOjQwOjI5Og0KDQo+IE9uIFdl
ZCwgU2VwIDE5LCAyMDEyIGF0IDEyOjE3IFBNLCBNYXJ0aW4gUmV4IDxtcmV4QHNhcC5jb20+IHdy
b3RlOg0KPiA+IFNvIGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciB3aGVyZSBpbiB0aGUgc29mdHdh
cmUgc3RhY2sgeW91IHBlcmZvcm0NCj4gPiBjb21wcmVzc2lvbi4gIFRoZSBwcm9ibGVtIG9jY3Vy
cyB3aGVuZXZlciBhdHRhY2tlci1zdXBwbGllZCBhbmQNCj4gPiBhc3N1bWVkIGNvbmZpZGVudGlh
bCBkYXRhIGlzIGZlZCBpbnRvIGEgY29tcHJlc3Npb24gZnVuY3Rpb24sIGFuZA0KPiA+IGRpZmZl
cmVuY2VzIGluIHRoZSByZXN1bHRpbmcgb3V0cHV0IGxlbmd0aCBjYW4gYmUgb2JzZXJ2ZWQgYnkg
dGhlDQo+ID4gYXR0YWNrZXIuDQo+IA0KPiBCeSBkb2luZyBjb21wcmVzc2lvbiBhdCB0aGUgYXBw
bGljYXRpb24gbGF5ZXIgd2UgYWxsb3cgdGhlIGFwcGxpY2F0aW9uDQo+IHRvIGRlY2lkZSB3aGlj
aCBkYXRhIGRlc2VydmUgYSBoaWdoZXIgcXVhbGl0eSBvZiBwcm90ZWN0aW9uLiAgU3RhdGljLA0K
PiBtaWdodC1hcy13ZWxsLWJlLXB1YmxpYyBkYXRhIGNhbiBiZSBjb21wcmVzc2VkLg0KT3IgbGV0
IHRoZSBhcHBsaWNhdGlvbiBsYXllciBhZGRzIHJhbmRvbSB0byBzZW5zaXRpdmUgZGF0YSBmaXJz
dCwgdGhlbiANCmNvbXByZXNzIGFuZCBlbmNyeXB0Pw0KDQo+IA0KPiBOaWNvDQo+IC0tDQo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWls
aW5nIGxpc3QNCj4gVExTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdGxzDQo+IA0KDQo=
--=_alternative 0036259D48257A7F_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50bHMtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMDkt
MjAgMDE6NDA6Mjk6PGJyPg0KPGJyPg0KJmd0OyBPbiBXZWQsIFNlcCAxOSwgMjAxMiBhdCAxMjox
NyBQTSwgTWFydGluIFJleCAmbHQ7bXJleEBzYXAuY29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyAm
Z3Q7IFNvIGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciB3aGVyZSBpbiB0aGUgc29mdHdhcmUgc3Rh
Y2sgeW91IHBlcmZvcm08YnI+DQomZ3Q7ICZndDsgY29tcHJlc3Npb24uICZuYnNwO1RoZSBwcm9i
bGVtIG9jY3VycyB3aGVuZXZlciBhdHRhY2tlci1zdXBwbGllZA0KYW5kPGJyPg0KJmd0OyAmZ3Q7
IGFzc3VtZWQgY29uZmlkZW50aWFsIGRhdGEgaXMgZmVkIGludG8gYSBjb21wcmVzc2lvbiBmdW5j
dGlvbiwNCmFuZDxicj4NCiZndDsgJmd0OyBkaWZmZXJlbmNlcyBpbiB0aGUgcmVzdWx0aW5nIG91
dHB1dCBsZW5ndGggY2FuIGJlIG9ic2VydmVkIGJ5DQp0aGU8YnI+DQomZ3Q7ICZndDsgYXR0YWNr
ZXIuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ5IGRvaW5nIGNvbXByZXNzaW9uIGF0IHRoZSBhcHBs
aWNhdGlvbiBsYXllciB3ZSBhbGxvdyB0aGUgYXBwbGljYXRpb248YnI+DQomZ3Q7IHRvIGRlY2lk
ZSB3aGljaCBkYXRhIGRlc2VydmUgYSBoaWdoZXIgcXVhbGl0eSBvZiBwcm90ZWN0aW9uLiAmbmJz
cDtTdGF0aWMsPGJyPg0KJmd0OyBtaWdodC1hcy13ZWxsLWJlLXB1YmxpYyBkYXRhIGNhbiBiZSBj
b21wcmVzc2VkLjxicj4NCk9yIGxldCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYWRkcyByYW5kb20g
dG8gc2Vuc2l0aXZlIGRhdGEgZmlyc3QsIHRoZW4NCmNvbXByZXNzIGFuZCBlbmNyeXB0PzwvZm9u
dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE5pY288
YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCiZndDsgVExTIG1haWxpbmcgbGlzdDxicj4NCiZndDsgVExTQGll
dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs
czxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 0036259D48257A7F_=--


From tom@ritter.vg  Thu Sep 20 06:14:38 2012
Return-Path: <tom@ritter.vg>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570AE21F867E for <tls@ietfa.amsl.com>; Thu, 20 Sep 2012 06:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.517
X-Spam-Level: 
X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vN-AGEDmZi6 for <tls@ietfa.amsl.com>; Thu, 20 Sep 2012 06:14:37 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 712E621F867C for <tls@ietf.org>; Thu, 20 Sep 2012 06:14:37 -0700 (PDT)
Received: by vbbfc26 with SMTP id fc26so2730858vbb.31 for <tls@ietf.org>; Thu, 20 Sep 2012 06:14:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ClnFt6CdpusfGrlDJaz9lwpb3oWEJAgHyglKTF70BQ4=; b=hJzE+xI1esYlLSrPldCjXX4iXkL8XzPMXiPv+zLPMbXlkA4DIfPdRi7kQ6WzIFZ/XJ N0cN5ugt9YZKuL2CO2+63gWjumekvThCiarkZFPGJuKmsu+1oSn/VyqKhkv8QbyxSPJR EnWjZw2yN4oPSDDSeXyNgd2VpA9NmMApHPxb8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ClnFt6CdpusfGrlDJaz9lwpb3oWEJAgHyglKTF70BQ4=; b=l/ak00zSrwkt0WW//SdYpMROzlGUZzjjeAMKAiF4zPdE0rHZp9vyk/dcG9YyZ0Ghuj PPjEMZ8VcPI3lgdnXcwGbQiZJBwOr94qPNl7wrwGOE/3AiqtM5aW2orDbM/tIH8Nb+cv ofeknV9V2+nNHNGOSoPcgQjPpCvmxtqu9QsWBbXV/eyUsamxAOruOI4U24IaD5Z+Aeuh ejXJyPIX6lKQrYDRCEcemUPqiaQrLqZXvXSSLUB8awGLECzduB8kqPlmipNGiaqgofsy XJIhDz1j1gdD2eEBN2Nb8yqTB0FP7yDa5H3NMwl+IPVA0DTYpVOTrUv6ZV3D88u9Th5o pLMg==
MIME-Version: 1.0
Received: by 10.220.221.131 with SMTP id ic3mr1010932vcb.46.1348146876831; Thu, 20 Sep 2012 06:14:36 -0700 (PDT)
Received: by 10.58.239.200 with HTTP; Thu, 20 Sep 2012 06:14:36 -0700 (PDT)
Received: by 10.58.239.200 with HTTP; Thu, 20 Sep 2012 06:14:36 -0700 (PDT)
In-Reply-To: <OF7AA95AAA.176D463E-ON48257A7F.0035D79A-48257A7F.0036259E@zte.com.cn>
References: <CAK3OfOh4JB2yZ=eo-Vei_zW+mYeARv3X0vL9o+=V5v5T4=DjjQ@mail.gmail.com> <OF7AA95AAA.176D463E-ON48257A7F.0035D79A-48257A7F.0036259E@zte.com.cn>
Date: Thu, 20 Sep 2012 09:14:36 -0400
Message-ID: <CA+cU71kTT5xHFRipDUrC+81J3878=sEECNTR-xuS4nfSr3G7YQ@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
To: zhou.sujing@zte.com.cn
Content-Type: multipart/alternative; boundary=14dae9cdcb93b2d95b04ca21e7dc
X-Gm-Message-State: ALoCoQl0JgNpC+qWZLLNfdiU0sDxfc3RD4dq6kODLLczusFWAUFN/k9+zcgYpOewIdFMlE5BH7ZH
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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, 20 Sep 2012 13:14:38 -0000

--14dae9cdcb93b2d95b04ca21e7dc
Content-Type: text/plain; charset=ISO-8859-1

On 20 September 2012 05:50, <zhou.sujing@zte.com.cn> wrote:
> Or let the application layer adds random to sensitive data first, then
> compress and encrypt?

You have to be careful, if the application always adds X bytes of random
data - it probably will just compress to the original length+X.

A friend and I were discussing this, and we came up with two different
ideas. Mine was to add random data (in an HTTP header) with a random
length, up to a limit L. The length of the random data was distributed
according to a Bell Curve, with random flattening/inflating parameters, to
make the curve somewhat random. I never attempted it (because I'm terrible
at statistics) but I believe with this you can mathematically prove an
attacker would need to issue, on average, a certain number more requests
per byte of data they wish to learn.

If the bell curve was instead an equal probability, they would need to
issue a little more than the maximum possible length of random data to be
certain the smallest length seen so far is indeed the smallest. With an
unaltered bell curve, they could fit the sizes onto a bell curve and know
when they had hit the short end. By randomly flattening or inflating the
bell curve you make the work harder. They could still bypass it, but you
can give a security boundary. "To protect a 9 byte secret, and attacker
would need to issue on average about 1,000,000 requests to learn each byte,
if you have a maximum random string length of X". Pump up X, pump up the
difficulty.

His idea was to instead make the deflate function randomly suboptimal.

My argument against that is that no matter what, the deflate function would
have a minimum size it can compress to, the optimal size M. What is the
probability of reaching M in your randomized deflate? If you prove it will
never reach M, then there's still an M' it *will* reach that is the new
minimum and that then becomes M. Again, what is the probability of seeing
M? Randomized Deflate will have to bucket between M and a maximum size. And
Randomized Deflate is a function of the Input I and the RNG R. (I,R) ->
{M...Max}. Although finding R is outside the possibility, hitting each
individual bucket is not.

An attacker just has to retry until they're reasonably sure they've seen M,
use the lowest length seen so far, pick it, and move on. But figuring out
the probability for finding M on a randomized deflate is waaaay harder than
calculating probabilities in a bell curve. The probabilities might say
"4,000,000 tries" or it might say "90". I know I couldn't even attempt to
figure that out, while I know the other is at least possible. So from my
perspective, you're basing your security on a hunch about randomized
deflate.

Those were two thoughts we had.

-tom

--14dae9cdcb93b2d95b04ca21e7dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On 20 September 2012 05:50, &lt;<a href=3D"mailto:zhou.sujin=
g@zte.com.cn">zhou.sujing@zte.com.cn</a>&gt; wrote:<br>
&gt; Or let the application layer adds random to sensitive data first, then=
<br>
&gt; compress and encrypt?</p>
<p dir=3D"ltr">You have to be careful, if the application always adds X byt=
es of random data - it probably will just compress to the original length+X=
.</p>
<p dir=3D"ltr">A friend and I were discussing this, and we came up with two=
 different ideas. Mine was to add random data (in an HTTP header) with a ra=
ndom length, up to a limit L. The length of the random data was distributed=
 according to a Bell Curve, with random flattening/inflating parameters, to=
 make the curve somewhat random. I never attempted it (because I&#39;m terr=
ible at statistics) but I believe with this you can mathematically prove an=
 attacker would need to issue, on average, a certain number more requests p=
er byte of data they wish to learn. </p>

<p dir=3D"ltr">If the bell curve was instead an equal probability, they wou=
ld need to issue a little more than the maximum possible length of random d=
ata to be certain the smallest length seen so far is indeed the smallest. W=
ith an unaltered bell curve, they could fit the sizes onto a bell curve and=
 know when they had hit the short end. By randomly flattening or inflating =
the bell curve you make the work harder. They could still bypass it, but yo=
u can give a security boundary. &quot;To protect a 9 byte secret, and attac=
ker would need to issue on average about 1,000,000 requests to learn each b=
yte, if you have a maximum random string length of X&quot;. Pump up X, pump=
 up the difficulty.</p>

<p dir=3D"ltr">His idea was to instead make the deflate function randomly s=
uboptimal. </p>
<p dir=3D"ltr">My argument against that is that no matter what, the deflate=
 function would have a minimum size it can compress to, the optimal size M.=
 What is the probability of reaching M in your randomized deflate? If you p=
rove it will never reach M, then there&#39;s still an M&#39; it *will* reac=
h that is the new minimum and that then becomes M. Again, what is the proba=
bility of seeing M? Randomized Deflate will have to bucket between M and a =
maximum size. And Randomized Deflate is a function of the Input I and the R=
NG R. (I,R) -&gt; {M...Max}. Although finding R is outside the possibility,=
 hitting each individual bucket is not.</p>

<p dir=3D"ltr">An attacker just has to retry until they&#39;re reasonably s=
ure they&#39;ve seen M, use the lowest length seen so far, pick it, and mov=
e on. But figuring out the probability for finding M on a randomized deflat=
e is waaaay harder than calculating probabilities in a bell curve. The prob=
abilities might say &quot;4,000,000 tries&quot; or it might say &quot;90&qu=
ot;. I know I couldn&#39;t even attempt to figure that out, while I know th=
e other is at least possible. So from my perspective, you&#39;re basing you=
r security on a hunch about randomized deflate.</p>

<p dir=3D"ltr">Those were two thoughts we had. </p>
<p dir=3D"ltr">-tom</p>

--14dae9cdcb93b2d95b04ca21e7dc--

From rrelyea@redhat.com  Thu Sep 20 16:54:24 2012
Return-Path: <rrelyea@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858A621E8047 for <tls@ietfa.amsl.com>; Thu, 20 Sep 2012 16:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX1n7NXOqJj8 for <tls@ietfa.amsl.com>; Thu, 20 Sep 2012 16:54:23 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8E21F869D for <tls@ietf.org>; Thu, 20 Sep 2012 16:54:23 -0700 (PDT)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8KNsMCG004790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <tls@ietf.org>; Thu, 20 Sep 2012 19:54:22 -0400
Received: from bobslaptop.local (unused-16-109.sjc.redhat.com [10.14.16.109]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q8KNsLpp005084 for <tls@ietf.org>; Thu, 20 Sep 2012 19:54:22 -0400
Message-ID: <505BACC1.2060503@REDHAT.COM>
Date: Thu, 20 Sep 2012 16:54:41 -0700
From: Robert Relyea <rrelyea@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120601 Thunderbird/10.0.5
MIME-Version: 1.0
To: tls@ietf.org
References: <87oblttqxj.fsf@pip.fifthhorseman.net> <CAL9PXLzGdgqkTSDHjHR_dpirLQxPf2kOJ4cfTsFSUGAkHWpTKQ@mail.gmail.com>
In-Reply-To: <CAL9PXLzGdgqkTSDHjHR_dpirLQxPf2kOJ4cfTsFSUGAkHWpTKQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050202070009040304040303"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Subject: Re: [TLS] shared secret keys between TLS clients: specific risks? OK in certain suites?
X-BeenThere: tls@ietf.org
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." <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, 20 Sep 2012 23:54:25 -0000

This is a cryptographically signed message in MIME format.

--------------ms050202070009040304040303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 08/29/2012 01:08 PM, Adam Langley wrote:
> On Wed, Aug 29, 2012 at 3:54 PM, Daniel Kahn Gillmor
> <dkg@fifthhorseman.net>  wrote:
>> This is a hypothetical question about an unusual use of TLS, a scenari=
o
>> which goes against all my instincts about reasonable key management.
>> I'm hoping for any insight or analysis that might help me understand t=
he
>> specific risks.
> DH/ECDH certificates would allow a private key holder to decrypt other
> connections made with the same client certificate.
So there are no TLS/SSL cipher suites where the clients have DH/ECDH=20
certificates. Client auth certs are always signing certs.

There are Ciphers where the server has a DH or ECDH cert, but the client =

exchange keys are all generated on the fly by the client. Each one would =

have a unique key and the others could not read it.

I'm not quite sure why you want to have a single key in these cases,=20
though. Signing key provisioning is pretty cheap... at least as cheap as =

trying to distribute pregenerated key/cert pairs. You can still keep=20
everyone in the same group with a rather anonymous certificates. With a=20
singer key/cert pair you have a pretty nasty recovery issue if you have=20
a private key compromise (and such a compromise seems more likely then=20
the normal client situation).

bob
>
> I believe that a signature based (RSA/ECDSA) client certificate is
> `safe' as a group authentication method in that one member of the
> group could not intercept/decrypt a connection made by another.
Adam is correct. And since all client auth certs are signing certs, you=20
are safe in general.
>
> "Group signatures" are a problem that has been studied and has a
> practical solution:
> http://crypto.stanford.edu/~dabo/papers/groupsigs.pdf, although the
> bilinear group presents an implementation challenge. ("Group
> signatures" in that case are defined to have slightly different
> properties, see the paper.)
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--------------ms050202070009040304040303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINkTCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHVTCCBj2gAwIBAgICJMgwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjA4MTQxMjI4NTFa
Fw0xNDA4MTUxNjI4MTJaMIGMMRkwFwYDVQQNExAzcDRtNUNFMXFsZGw4cWdFMQswCQYDVQQG
EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2YWxlMRYwFAYDVQQD
Ew1Sb2JlcnQgUmVseWVhMSEwHwYJKoZIhvcNAQkBFhJycmVseWVhQHJlZGhhdC5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8I8X2rzySfdhry2UpHNYDJrPFBGGZfrvo
HB/pqrbiErgmOfwLn58vTvZ7y0ffj87h3zKy6gY40G9qoh1DiWcMqwazI3jn04GrdXA4fs3q
hLpxaZMjpFSkrJT58alI7TAAFWyOgUpGfITPiU4Wc0hLndCfxy74HNcJy+6Eg1TVqgeluE/p
UYYIcpgZeglG7e388I4YIRP0oJFUzOE/LinuwFechkcWMZIxUpEtqMvi3FeZGUNRat3oD4HC
3kyU8wxeVC9BqX4mOFljFS3Qcabu3KBRHm3GKzuavBvKj3dKXEQYimheHgpasHONAUYrzcQh
tbgKGtXGlUotKAJPVgwnAgMBAAGjggO9MIIDuTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBYIZ6wAm67LQRDsUbWZ
owGbTyW4MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MC0GA1UdEQQmMCSBEnJy
ZWx5ZWFAcmVkaGF0LmNvbYEOYm9iQHJlbHllYS5jb20wggIhBgNVHSAEggIYMIICFDCCAhAG
CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v
cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt
ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg
dG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g
Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF
BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp
bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu
ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr
oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH
AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz
czIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0
cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBXvSJvvWbQd8Bjg5MEau33KCUHezDnQQsJ
xW2UHU3chOSETMDEo46PORrakvF4N8Wl4NMp71xYv5uSaZh3HZYqbgyG1s3YVOCpzv2LsTwe
hPUwtSI8RC5YHtjPefGtBv3FCT5ImNxuCXs0JGpY/3Xllg10Cv2A9VjwBuWFx2gTLiPRIxpS
wqpNY8yiWORhjvJgvgzW90DT0Z0rOK7zQPgyvfYBm1m5YThUZq8FDzy4XUMvABdldLF4EQ/3
l1siYe4aib9buKt5oDTriV+8JYC7EFKx+Mh4M68sQIsk2G+w3JHrK1DPfBQ6G6u2l1oD07gE
absmRyKOxe80dcAX3f6NMYIDzTCCA8kCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT
aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQQICJMgwCQYFKw4DAhoFAKCCAg4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTIwOTIwMjM1NDQxWjAjBgkqhkiG9w0BCQQxFgQUF48r7+Ua
dwgCMv63U0mQHUq3UzQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu
dCBDQQICJMgwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0ECAiTIMA0GCSqGSIb3DQEBAQUABIIBABYvadh3eaf/Os5sASOrw6ovDyvj
pJ3jmSOwOsBO9bpFBS21TJo4uU22UN7iyjLAbBjzkAoqGN34q6R0Ty4sZUXCvRU8hDCDLqf5
XNjjaFvw0vK2b3POTS9IauOYj3uo12ABONnv2JSaA18XNruMwpi0/bkAnB7E1LyJRKzOcwuJ
rIqBAmzNX8bUddIKtk3iI1KrD4u4D7DGFhz+dMMk83vAWETwomwRQvHTWQsRz/wY7fkorhnX
J7xAh4BraexnB/zmZLEXa9/7UNnSgs7lkxjz71GjC2vQZLo5CO17lsJP8BRiwEHerOrCRaIG
5yCdnkIvHzj3h2S0pGQP71tqNycAAAAAAAA=
--------------ms050202070009040304040303--

From zhou.sujing@zte.com.cn  Thu Sep 20 20:09:13 2012
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6121E805F; Thu, 20 Sep 2012 20:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.714
X-Spam-Level: 
X-Spam-Status: No, score=-94.714 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mje1XVn8Su1H; Thu, 20 Sep 2012 20:09:09 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D26E021E8056; Thu, 20 Sep 2012 20:09:08 -0700 (PDT)
Received: from [10.30.3.20] by mx5.zte.com.cn with surfront esmtp id 551312220468675(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO);  Fri, 21 Sep 2012 11:01:07 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q8L38s41084113; Fri, 21 Sep 2012 11:08:54 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <505792AB.5000207@gnutls.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF94A8F544.AC257F65-ON48257A80.000CDBF6-48257A80.00115D1A@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Fri, 21 Sep 2012 11:08:40 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-21 11:08:47, Serialize complete at 2012-09-21 11:08:47
Content-Type: multipart/alternative; boundary="=_alternative 00115D1848257A80_="
X-MAIL: mse01.zte.com.cn q8L38s41084113
Cc: tls-bounces@ietf.org, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] mitigate the attack on TLS compression
X-BeenThere: tls@ietf.org
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." <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: Fri, 21 Sep 2012 03:09:13 -0000

This is a multipart message in MIME format.
--=_alternative 00115D1848257A80_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

QWZ0ZXIgcmVhZGluZyB0aGUgdGhyZWFkLCBJIGdhdmUgYSBzaG9ydCBzdW1tYXJ5IG9uIHByb3Bv
c2VkIA0KY291bnRlcm1lYXN1cmVzOg0KMS4gc3RhdGVmdWwgY29tcHJlc3Npb24gLS0+IHN0YXRl
bGVzcyBjb21wcmVzc2lvbi4gICAgICAgICBub3Qgd29ya2FibGUgaW4gDQpzb21lIGNhc2VzDQoy
LiBkaXNhYmxlIFRMUy9TU0wgY29tcHJlc3Npb24uICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHdvcmtzIGJ1dCBhIA0Kd2FzdGUgb2YgYmFuZHdpZHRoDQozLiByYW5kb21pemluZyBwbGFpbnRl
eHQgKG9yIHBhcnQgb2Ygc2Vuc2l0aXZlIHBsYWludGV4dCkgZmlyc3QuICAgZS5nLiwgDQogICAg
ICAgICAgIHByZSBhbmQgYXBwZW5kIHBsYWludGV4dCB3aXRoIHJhbmRvbWx5IHNpemVkIHJhbmRv
bSBwYWRkaW5nLiANCmNvdW50ZXIgdG8gcHVycG9zZSBvZiBjb21wcmVzc2lvbg0KICAgICAgICAg
ICBlbmNyeXB0IHBsYWludGV4dCAob3Igc2Vuc2l0aXZlIGRhdGEgb25seSkgZmlyc3QgYXQgYXBw
bGljYXRpb24gDQpsZXZlbCBtaWdodCBiZSBhbm90aGVyICBzb2x1dGlvbi4gZG91YmxlIGVuY3J5
cHRpb24sIG1pZ2h0IGJlIHJlcXVpcmVkIGZvciANCmhpZ2ggdmFsdWUgc2l0ZXM7IGVuY3J5cHRp
b24gKGFsbCBwbGFpbnRleHQpIG1ha2VzIGNvbXByZXNzaW9uIGluIFRMUyANCm1lYW5pbmcgbGVz
cyANCjQuIGNvbXByZXNzaW9uIG9ubHkgbm9uLXNlbnNpdGl2ZSBkYXRhIGF0IGFwcGxpY2F0aW9u
IGxldmVsIGZpcnN0LiAgbmVlZCANCnRvIGNoYW5nZSBhcHBsaWNhdGlvbi4NCjUuIE15IG9waW5p
b24gaXMgOiB0aGUgcmF0aW9uYWxlIG9mIHRoZSBhdHRhY2sgaXMgOiBjb21wcmVzc2lvbiB0dXJu
cyANCnBhbGludGV4dCBpbmZvcm1hdGlvbiAoYW5kIHBsYWludGV4dCByZWxhdGlvbiBpbmZvcm1h
dGlvbikgaW50byBsZW5ndGggDQppbmZvcm1hdGlvbiwgYnV0IGxlbmd0aCBpbmZvcm1hdGlvbiBp
cyBub3QgcHJvdGVjdGVkIGJ5IGVuY3J5cHRpb24uIEluIA0KY2FzZXMgY29tcHJlc3Npb24gaW5w
dXQgaXMgYWxsIGdlbmVyYXRlZCBieSBnZW51aW5lIGFwcGxpY2F0aW9uLCBpdCBzZWVtcyANCm9r
LCBidXQgd2hlbiBjb21wcmVzc2lvbiBpbnB1dCBjb3VsZCBiZSBtYW5pcHVsYXRlZCBieSBhdHRh
Y2tlcnMsIHByb2JsZW1zIA0KYXJpc2UuIEFuZCBpdCBhZ2FpbiBhdHRlc3RlZCBvbmUgcHJpbmNp
cGxlIGluIGNyeXB0b2dyYXBoeTogbmV2ZXIgYmxpbmRseSANCmVuY3J5cHQgYW55IHBsYWludGV4
LCBiZXR0ZXIgZG8gZGF0YSBpbnRlZ3JpdHkgYW5kIGVuc3VyZSBwYWludGV4dCANCnNlbWFudGlj
cyBiZWZvcmUgZW5jcnlwdGlvbihJIGFtIHNvcnJ5IGZvciB0aGUgY2x1bXN5IHdvcmRzKS4NClNv
IHRoZSBhdHRhY2tlIG1pZ2h0IGJlIGNvdW50ZXJlZCBieSBlbnN1cmluZyBpbnB1dCB0byBUTFMg
KGNvbXByZXNzaW9uIA0KYW5kIGVuY3J5cHRpb24pIGlzIHN0cmljdGx5IGdlbmVyYXRlZCBieSBh
cHBsaWNhdGlvbnMuIA0KDQp0bHMtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMDktMTggMDU6
MTQ6MTk6DQoNCj4gSGVsbG8sDQo+ICBJJ20gd29uZGVyaW5nIGhvdyBvdGhlciBpbXBsZW1lbnRl
cnMgbWl0aWdhdGVkIHRoZSBSaXp6bydzIGF0dGFjayBvbg0KPiBUTFMgY29tcHJlc3Npb24gWzBd
LiBXaGF0IEkndmUgY3VycmVudGx5IGRvbmUgaXMgdG8gc3VnZ2VzdDoNCj4gMS4gdG8gZGlzYWJs
ZSBjb21wcmVzc2lvbg0KPiAyLiBJZiB5b3UgbmVlZCBjb21wcmVzc2lvbiB1c2UgQ0JDIHJhbmRv
bSBwYWRkaW5nDQo+IA0KPiBhbmQgSSBwbGFuIHRvIGFkZCBhIHN0YXRlbGVzcyBjb21wcmVzc2lv
biBtb2RlICh3aGljaCB2aW9sYXRlcyBSRkMzNzQ5KS4NCj4gQW55IG90aGVyIGlkZWFzPw0KPiAN
Cj4gcmVnYXJkcywNCj4gTmlrb3MNCj4gDQo+IA0KPiBbMF0uDQo+IGh0dHA6Ly9zZWN1cml0eS5i
bG9nb3ZlcmZsb3cuY29tLzIwMTIvMDkvaG93LWNhbi15b3UtcHJvdGVjdC0NCj4geW91cnNlbGYt
ZnJvbS1jcmltZS1iZWFzdHMtc3VjY2Vzc29yLw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9y
Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPiANCg0K
--=_alternative 00115D1848257A80_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFmdGVyIHJlYWRpbmcgdGhlIHRo
cmVhZCwgSSBnYXZlIGEgc2hvcnQNCnN1bW1hcnkgb24gcHJvcG9zZWQgY291bnRlcm1lYXN1cmVz
OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gc3RhdGVmdWwg
Y29tcHJlc3Npb24gLS0mZ3Q7IHN0YXRlbGVzcw0KY29tcHJlc3Npb24uICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBub3Qgd29ya2FibGUgaW4gc29tZSBjYXNlczwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gZGlzYWJsZSBUTFMvU1NMIGNvbXByZXNzaW9u
LiAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDt3b3JrcyBidXQgYSB3
YXN0ZSBvZiBiYW5kd2lkdGg8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPjMuIHJhbmRvbWl6aW5nIHBsYWludGV4dCAob3IgcGFydCBvZg0Kc2Vuc2l0aXZlIHBsYWlu
dGV4dCkgZmlyc3QuICZuYnNwOyBlLmcuLCAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7cHJlDQphbmQgYXBwZW5kIHBsYWludGV4dCB3aXRoIHJhbmRvbWx5IHNpemVkIHJhbmRvbSBw
YWRkaW5nLiAmbmJzcDsgJm5ic3A7Y291bnRlcg0KdG8gcHVycG9zZSBvZiBjb21wcmVzc2lvbjwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbmNyeXB0DQpwbGFpbnRleHQgKG9yIHNlbnNpdGl2
ZSBkYXRhIG9ubHkpIGZpcnN0IGF0IGFwcGxpY2F0aW9uIGxldmVsIG1pZ2h0IGJlDQphbm90aGVy
ICZuYnNwO3NvbHV0aW9uLiBkb3VibGUgZW5jcnlwdGlvbiwgbWlnaHQgYmUgcmVxdWlyZWQgZm9y
IGhpZ2ggdmFsdWUNCnNpdGVzOyBlbmNyeXB0aW9uIChhbGwgcGxhaW50ZXh0KSBtYWtlcyBjb21w
cmVzc2lvbiBpbiBUTFMgbWVhbmluZyBsZXNzDQombmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjQuIGNvbXByZXNzaW9uIG9ubHkgbm9uLXNlbnNpdGl2ZSBk
YXRhDQphdCBhcHBsaWNhdGlvbiBsZXZlbCBmaXJzdC4gJm5ic3A7bmVlZCB0byBjaGFuZ2UgYXBw
bGljYXRpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj41LiBN
eSBvcGluaW9uIGlzIDogdGhlIHJhdGlvbmFsZSBvZg0KdGhlIGF0dGFjayBpcyA6IGNvbXByZXNz
aW9uIHR1cm5zIHBhbGludGV4dCBpbmZvcm1hdGlvbiAoYW5kIHBsYWludGV4dA0KcmVsYXRpb24g
aW5mb3JtYXRpb24pIGludG8gbGVuZ3RoIGluZm9ybWF0aW9uLCBidXQgbGVuZ3RoIGluZm9ybWF0
aW9uIGlzDQpub3QgcHJvdGVjdGVkIGJ5IGVuY3J5cHRpb24uIEluIGNhc2VzIGNvbXByZXNzaW9u
IGlucHV0IGlzIGFsbCBnZW5lcmF0ZWQNCmJ5IGdlbnVpbmUgYXBwbGljYXRpb24sIGl0IHNlZW1z
IG9rLCBidXQgd2hlbiBjb21wcmVzc2lvbiBpbnB1dCBjb3VsZCBiZQ0KbWFuaXB1bGF0ZWQgYnkg
YXR0YWNrZXJzLCBwcm9ibGVtcyBhcmlzZS4gQW5kIGl0IGFnYWluIGF0dGVzdGVkIG9uZSBwcmlu
Y2lwbGUNCmluIGNyeXB0b2dyYXBoeTogbmV2ZXIgYmxpbmRseSBlbmNyeXB0IGFueSBwbGFpbnRl
eCwgYmV0dGVyIGRvIGRhdGEgaW50ZWdyaXR5DQphbmQgZW5zdXJlIHBhaW50ZXh0IHNlbWFudGlj
cyBiZWZvcmUgZW5jcnlwdGlvbihJIGFtIHNvcnJ5IGZvciB0aGUgY2x1bXN5DQp3b3JkcykuPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbyB0aGUgYXR0YWNrZSBt
aWdodCBiZSBjb3VudGVyZWQgYnkNCmVuc3VyaW5nIGlucHV0IHRvIFRMUyAoY29tcHJlc3Npb24g
YW5kIGVuY3J5cHRpb24pIGlzIHN0cmljdGx5IGdlbmVyYXRlZA0KYnkgYXBwbGljYXRpb25zLiAm
bmJzcDsgPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dGxzLWJvdW5jZXNAaWV0
Zi5vcmcg0LTT2iAyMDEyLTA5LTE4IDA1OjE0OjE5Ojxicj4NCjxicj4NCiZndDsgSGVsbG8sPGJy
Pg0KJmd0OyAmbmJzcDtJJ20gd29uZGVyaW5nIGhvdyBvdGhlciBpbXBsZW1lbnRlcnMgbWl0aWdh
dGVkIHRoZSBSaXp6bydzIGF0dGFjaw0Kb248YnI+DQomZ3Q7IFRMUyBjb21wcmVzc2lvbiBbMF0u
IFdoYXQgSSd2ZSBjdXJyZW50bHkgZG9uZSBpcyB0byBzdWdnZXN0Ojxicj4NCiZndDsgMS4gdG8g
ZGlzYWJsZSBjb21wcmVzc2lvbjxicj4NCiZndDsgMi4gSWYgeW91IG5lZWQgY29tcHJlc3Npb24g
dXNlIENCQyByYW5kb20gcGFkZGluZzxicj4NCiZndDsgPGJyPg0KJmd0OyBhbmQgSSBwbGFuIHRv
IGFkZCBhIHN0YXRlbGVzcyBjb21wcmVzc2lvbiBtb2RlICh3aGljaCB2aW9sYXRlcyBSRkMzNzQ5
KS48YnI+DQomZ3Q7IEFueSBvdGhlciBpZGVhcz88YnI+DQomZ3Q7IDxicj4NCiZndDsgcmVnYXJk
cyw8YnI+DQomZ3Q7IE5pa29zPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgWzBdLjxi
cj4NCiZndDsgaHR0cDovL3NlY3VyaXR5LmJsb2dvdmVyZmxvdy5jb20vMjAxMi8wOS9ob3ctY2Fu
LXlvdS1wcm90ZWN0LTxicj4NCiZndDsgeW91cnNlbGYtZnJvbS1jcmltZS1iZWFzdHMtc3VjY2Vz
c29yLzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQomZ3Q7IFRMUyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFRMU0BpZXRmLm9yZzxi
cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8YnI+DQom
Z3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K
--=_alternative 00115D1848257A80_=--


From ekr@rtfm.com  Tue Sep 25 19:46:50 2012
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9E1F041E for <tls@ietfa.amsl.com>; Tue, 25 Sep 2012 19:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXDYRUFNUjDW for <tls@ietfa.amsl.com>; Tue, 25 Sep 2012 19:46:50 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0752E1F0C96 for <tls@ietf.org>; Tue, 25 Sep 2012 19:46:49 -0700 (PDT)
Received: by eekd4 with SMTP id d4so37798eek.31 for <tls@ietf.org>; Tue, 25 Sep 2012 19:46:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=c45ZSr/zwS8S8332tvHQxPCWBVB23oEktNwvBjaKIVw=; b=gw2UxMdN0oXHxbW/+H5bwXqYWHUAUY0UWO/igLnnFyQYGyNDmOeFtNfmwPAB373WSL GZVCvZ04yBJQkjg4nxB8zJkhQ+RsXkXYdWvaGFCJexBPOYtD9GWPVNY/k/JdVjBtckpq hLg1hmgWW4UXdKQGL9E9oAzS/bqrMzGYKAY/P2jClkbv0lvdMPciGRWeC71DCsLD9SyK JeDRL866wjF7vJNUKn0oJb6BuoMa+6lpxyN6Q64+BE+/aPekr0/G8+sQSumxmp88Of/T j9OumHHKBzvdLpi9+qub8pQfBKBxafHK9XfWbrjmwWxtpGqmnyuuTvn+b7TZP5o60qgD /3jw==
Received: by 10.14.193.136 with SMTP id k8mr23322505een.9.1348627609144; Tue, 25 Sep 2012 19:46:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.174.6 with HTTP; Tue, 25 Sep 2012 19:46:08 -0700 (PDT)
X-Originating-IP: [74.95.2.169]
In-Reply-To: <5058A2C1.5000602@ieca.com>
References: <20120918161313.20374.9674.idtracker@ietfa.amsl.com> <5058A2C1.5000602@ieca.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 25 Sep 2012 19:46:08 -0700
Message-ID: <CABcZeBOS3HQKu302Gi+KRZsnFn0gzQ51v2u_ow7tTmynZOh9Ng@mail.gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkO6y3HzsLkaNixkqRtVpcqd2bjsX38WA1dUlJXH5lDhvwI0fu3r3oLN5IpjfvWoWCRc5Wj
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: [secdir] [new-work] WG Review: Hypertext Transfer Protocol Bis (httpbis)
X-BeenThere: tls@ietf.org
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." <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, 26 Sep 2012 02:46:50 -0000

This looks basically good, but I think some minor clarification might
be in order
to note that any 2818 bis would be in TLS.

E.g.,

> Explicitly out-of-scope items include:
> * Specifying the use of alternate transport-layer protocols. Note that it
>
>   is expected that the Working Group will work with the TLS working group
>   to define how the protocol is used with the TLS Protocol.

Add: any revisions to RFC 2818 will be done in the TLS WG.

-Ekr

From trevp@trevp.net  Wed Sep 26 06:36:49 2012
Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAA521F8863 for <tls@ietfa.amsl.com>; Wed, 26 Sep 2012 06:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1VkBwqh990B for <tls@ietfa.amsl.com>; Wed, 26 Sep 2012 06:36:49 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24721F8860 for <tls@ietf.org>; Wed, 26 Sep 2012 06:36:49 -0700 (PDT)
Received: by vcbfl11 with SMTP id fl11so666796vcb.31 for <tls@ietf.org>; Wed, 26 Sep 2012 06:36:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=iYiexMoIYQOJ0NbJ8C7pqq2Mvigv5FMGCW7u1e7o/Jk=; b=kbQmRzvtXOf3CWUClAwUg1Vr8qa5segW4bBbCdrCuYNOPVQOkCGPlWxVqMgDOxwa/g k+YgHUmAlH7x9r8lSv73idpWXXmteEagKBAs4GBBtm1fvV7nWVz6JdIWjo7o5tp3HUof IJGTsigdDk8gsVdCpCy74PIx+ICGw5ihKck5qQDdtKO7Y57b4me9AtV4Lz605T/IdPyt xToPMOJ2SNnoUulpXMUdqErbNo+o6T+4NkWnrtwMEkkuQWSCSXgfXOzpfUbI62+J4T+g CAzMNYyBOA77bguXWWL8h5H5ugociPWpdRFCo1n1jSLEBiH730h96cjQW9nwX6S4gF80 G5yA==
MIME-Version: 1.0
Received: by 10.220.154.6 with SMTP id m6mr253530vcw.51.1348666608497; Wed, 26 Sep 2012 06:36:48 -0700 (PDT)
Received: by 10.52.24.36 with HTTP; Wed, 26 Sep 2012 06:36:48 -0700 (PDT)
X-Originating-IP: [24.215.229.139]
Date: Wed, 26 Sep 2012 09:36:48 -0400
Message-ID: <CAGZ8ZG3-fXNO2f_vRnQFzd3e2gq5YRKVHFq-Uxt=9srRqZGxag@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: tls@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnP/m4pDAynPz0EEvgl5hopwZjZE2wXr2dTbnjyeZ2N5whc9hi1q68ssFW/Zh8MUenNyDKm
Cc: IETF WebSec WG <websec@ietf.org>
Subject: [TLS] TACK draft 01
X-BeenThere: tls@ietf.org
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." <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, 26 Sep 2012 13:36:50 -0000

Hi TLS (cc websec),

There's a new TACK draft: http://tools.ietf.org/html/draft-perrin-tls-tack-01

You can find code and other resources at http://tack.io

We'd love to get feedback or answer questions.  We'd also appreciate
advice on whether this should remain an individual submission or would
make sense as a WG document.


Changes
--------
The main change is that we removed break signatures.  Instead, servers
may optionally publish a second tack.  Clients can form two pins for a
hostname.

These changes let a server publish tacks from a new TACK key prior to
deactivating and removing the old key's tacks.  This "rollover" is a
better way to handle a compromised or suspect TACK key because it
preserves any security offered by the old key while the new one is
being introduced.

Other changes:

 * Rewrote "Client processing" to improve clarity.

 * Renamed
   "TACK" structure to "tack"
   "TACK_Extension" to "TackExtension"
   "pin_activation" field to "activation_flags"
   "TACK ID" to "key fingerprint"

 * Simplified error alerts sent by clients (and aligned with RFC 5878)

 * Deleted old section "6.2 Application-specific pinning", which was
too vague to be useful. Added new 6.1 and 6.2 discussing
considerations with different application protocols.

 * Changed server_name extension in ClientHello from SHOULD to SHALL.

 * Tweaked the Advice for Server Operators (8.1) regarding Tack expiration.


Trevor

From n.mavrogiannopoulos@gmail.com  Sat Sep 29 22:29:31 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420A21F85E6 for <tls@ietfa.amsl.com>; Sat, 29 Sep 2012 22:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQmhGtclMsLS for <tls@ietfa.amsl.com>; Sat, 29 Sep 2012 22:29:31 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B821F84CF for <tls@ietf.org>; Sat, 29 Sep 2012 22:29:30 -0700 (PDT)
Received: by eekd4 with SMTP id d4so2039377eek.31 for <tls@ietf.org>; Sat, 29 Sep 2012 22:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=2LxcGt7WT1CVAq0EgCYrOeFhW80Luw4nF7XJsgEp8pA=; b=WKnOyqczUhShFAJAKPqFNdSgRxrMoghHMUIqyFwPEahg7YmsGc3VTACDaHYcFHzkSt 6nt+AVOCfBQjLAa/im/6Xgwewz3DXPfRR+3MTWlAzcMzSfbvtQtqiViEl5hcIdwyuynt ZOnCg4idFe5JmpHNyswiS4EuszN0x/gOP5nKeo13byT6b6bBX3vFKRl5Zw7Zca7VPEOM IgiwZWMvuh6xJ+BX/6R5BbvmomF2ReY/Do/pEpFInRYqWqH6phdwbaKSCp6Rt3uY0TCE 6iwQUe7EXLm1mAaC/XBOXJOa8zGd7Uf5GCdXjkdhuNr1hHComS6LRZpdwrQtMZ9hRIx1 /AqA==
Received: by 10.14.179.136 with SMTP id h8mr14224318eem.6.1348982969851; Sat, 29 Sep 2012 22:29:29 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id 7sm31448567eej.13.2012.09.29.22.29.28 (version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 22:29:29 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5067D8B2.3080405@gnutls.org>
Date: Sun, 30 Sep 2012 07:29:22 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>, yngve@opera.com
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [TLS] comments on draft-ietf-tls-multiple-cert-status-extension-01
X-BeenThere: tls@ietf.org
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." <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: Sun, 30 Sep 2012 05:29:31 -0000

* Section 2.2:
The document says:
"In the OCSPStatusRequest and SCVPStatusRequest structures, the
   "ResponderIDs" provide a list of OCSP and SCVP responders
   (respectively) that the client trusts.  A zero-length
   "responder_id_list" sequence has the special meaning that the
   responders are implicitly known to the server, e.g., by prior
   arrangement, or are identfied by the certificates used by the server."

This is from RFC6066, but I think this text is only applicable to
original intent of the ocsp extension, as an extension for constrained
embedded clients. This is not valid generally, as most (if not all)
browsers always send a zero-length responder_id_list irrespective of any
prior arrangement with the server (there is none). The empty
responder_id_list indicates that the client would accept the preferred
by the server OCSP responder.

* same section:
'"Extensions" is a DER encoding of OCSP request extensions.'

I cannot understand the intent of the extensions. Is this field really
required, or the draft could be simplified by removing it? My guess is
that this is a relic of the original intention of the extension which
assumed that the server would poll the ocsp server at the moment the
client connected at his request. Are there any actual clients that use
this field on the current RFC6066 extension?

* same section:
     struct {
       OCSPResponse ocsp_response_list<1..2^24-1>
     } OCSPResponseList

there is a missing ';'

* same section:
   "Clients requesting a certificate response and receiving either one or
   more OCSP responses or a SCVP response in a "CertificateStatus"
   message MUST check the response(s) and abort the handshake, if the
   response is a revoked status or is otherwise not satisfactory with a
   bad_certificate_status_response(113) alert.  This alert is always
   fatal."

This text doesn't seem to belong in this section. There should be in a
verification section or so. However my question is whether this text is
applicable to this document at all. Is this document the proper place to
define what to do when OCSP verification fails? If there is some TLS
verification profile later that would like to set some verification
rules, it risks violating the OCSP extension draft.

I'd suggest, if you want to keep this text, to keep it pure
informational without MUSTs or SHOULDs.

regards,
Nikos


From n.mavrogiannopoulos@gmail.com  Sat Sep 29 22:37:24 2012
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D441A21F84D2 for <tls@ietfa.amsl.com>; Sat, 29 Sep 2012 22:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FXBPRm-v-0Y for <tls@ietfa.amsl.com>; Sat, 29 Sep 2012 22:37:24 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 225DB21F847F for <tls@ietf.org>; Sat, 29 Sep 2012 22:37:23 -0700 (PDT)
Received: by eaak13 with SMTP id k13so1506893eaa.31 for <tls@ietf.org>; Sat, 29 Sep 2012 22:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=ziYyqvhc46tygsl6HuM9VCG/iyI+QqauMhMSX/4CRM4=; b=EUW9zIuRIr42rsa9pyvgEKWwpWT+RknAn5AocQU1AYvKOw3ISoeMCO9ZRQ19a8TJPU yGrVtPYyDYkan6zpUUOuBam8w6hi2m7V0Bn0n0bAYXrcWZwTLGwQ1DrFUxMW9u/Z//dw EY1TW/GE6J8AaLvX9tWVJMkd1mKTMXDRiq762ln6+r0s0aaPhbsGkj+0Lf0DAjOz1zSa Bq9m+cxl8JZjgcoWgMqpwhEhhrCQpey/cePBC10+OKa1QCdsaCIr/8Sm5ETlzjPfOvqv 8Kt6CPR4IOot89jWVmR9BiLhOq1hqgpQIoPt+/IJy4Y1R2G57Y6mFE6NbCHcdddKakxq zc/Q==
Received: by 10.14.178.72 with SMTP id e48mr14473788eem.1.1348983443262; Sat, 29 Sep 2012 22:37:23 -0700 (PDT)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id y1sm38130589eel.0.2012.09.29.22.37.21 (version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 22:37:22 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5067DA8C.80809@gnutls.org>
Date: Sun, 30 Sep 2012 07:37:16 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>, yngve@opera.com
References: <5067D8B2.3080405@gnutls.org>
In-Reply-To: <5067D8B2.3080405@gnutls.org>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] comments on draft-ietf-tls-multiple-cert-status-extension-01
X-BeenThere: tls@ietf.org
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." <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: Sun, 30 Sep 2012 05:37:24 -0000

btw. There are no suggested values for XX, YY, and AA. There cannot be
interoperable implementation without some hint on these values.

regards,
Nikos