From nobody Thu May 1 09:13:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C257C1A6F82 for ; Thu, 1 May 2014 09:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s6xJ_c1UlWR for ; Thu, 1 May 2014 09:13:23 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D61A08D0 for ; Thu, 1 May 2014 09:13:23 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 19B334824D for ; Thu, 1 May 2014 16:13:21 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 0E0FA48241 for ; Thu, 1 May 2014 16:13:21 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id D99412FD60 for ; Thu, 1 May 2014 16:13:20 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 1 May 2014 12:13:19 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 1 May 2014 12:13:19 -0400 Thread-Topic: Presentation language parser on github Thread-Index: Ac9lV8x4tshPW+brQDmK4G9LtfVnvQ== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sEidev8a9kV4Pt27H67cZTjZSn8 Subject: [TLS] Presentation language parser on github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:13:25 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some folks may remember I wrote a parser for the language used in the TLS R= FC's. I put it on github, https://github.com/richsalz/tlsparser As a learn= ing exercise in git. There are some minor nits and such that I'll raise issues for. BTW, better= to open an issue, make a fix and do a pull request (more learning!) or bot= h? The biggest one is that "ASN1.Cert" is used all over the place, and that pe= riod is annoying to the parser. Can we make the usage be "ASN1Cert" through= out? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some folks may r= emember I wrote a parser for the language used in the TLS RFC’s. = ; I put it on github, htt= ps://github.com/richsalz/tlsparser As a learning exercise in git.<= /o:p>

 

The= re are some minor nits and such that I’ll raise issues for.  BTW= , better to open an issue, make a fix and do a pull request (more learning!= ) or both?

 

The biggest one is that “ASN1.Cert” is used all ov= er the place, and that period is annoying to the parser. Can we make the us= age be “ASN1Cert” throughout?

 

-- 

Principal Security Engineer

Akamai Technologies, Cambridge, MA

IM:= rsalz@jabber.me; Twitter: RichSalz<= o:p>

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0USMBX1msgcorp_-- From nobody Thu May 1 10:02:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457EA1A08F2 for ; Thu, 1 May 2014 10:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMMTx0UOh6qe for ; Thu, 1 May 2014 10:02:10 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.142.20]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2D1A073F for ; Thu, 1 May 2014 10:02:10 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 94480607E95D8; Thu, 1 May 2014 12:02:08 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id ACDA0607E90B1 for ; Thu, 1 May 2014 12:02:07 -0500 (CDT) Received: from [96.231.225.192] (port=50310 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WfuN5-0004ZV-4y for tls@ietf.org; Thu, 01 May 2014 12:02:07 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 1 May 2014 13:02:04 -0400 References: To: "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 96.231.225.192 X-Exim-ID: 1WfuN5-0004ZV-4y X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:50310 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JyDfKHKkjfaV8BD6TumaCyiiGis Subject: [TLS] Fwd: Call for volunteers for C/C++ API liaison manager X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:02:11 -0000 In case you=92re not subscribed to the ietf discuss list. spt Begin forwarded message: > From: IAB Chair > Subject: Call for volunteers for C/C++ API liaison manager > Date: April 30, 2014 at 11:20:31 EDT > To: IETF Announce > Cc: IAB , IETF > Reply-To: IAB >=20 > We often see proposals for APIs (most commonly C APIs) discussed in = the IETF. ISO/IEC JTC1/SC22 is the standards body for various = programming languages, notably including C (WG14) and C++ (WG21), and = those groups have been working on APIs for various IETF technologies, = including URIs, sockets, IP addresses, etc. The IAB is considering = whether to request a liaison relationship with ISO/IEC JTC1/SC22 and is = seeking to determine if there are candidates willing to serve as a = liaison manager before determining whether to request the relationship. = For details on what a liaison manager position entails, see RFC 4052, = RFC 4053, and RFC 4691. >=20 > Volunteers are requested to send email to iab@iab.org by May 28, 2014. >=20 > On behalf of the IAB, > Russ Housley > IAB Chair From nobody Thu May 1 11:02:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699F41A6FE0 for ; Thu, 1 May 2014 11:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB_4TRlWmdCx for ; Thu, 1 May 2014 11:02:41 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 104991A6FDE for ; Thu, 1 May 2014 11:02:40 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi5so1148614wib.4 for ; Thu, 01 May 2014 11:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=93qHfKztnGjHQJ5tantTFqKChnYUxMfRYTv+3JoL0QI=; b=lIdnGDWwoy5eCqd+zuBwS0PPjkdbiXnOAoUEEUUNRvXqaAFtwNymOZexf7fghHqoIf QMDAXYw1SUt3UnqqmfajLo8FLu6SAa/A86lrtmEIiX/gUem2ycP703rz2DxUiZlR4pXY HJYMHAMYFk12cR+uneyRUmH4I7D1K3erzTTV76fiFf4KInfryPygLycjqlDLycvM3sgy algWxQpiG/ep3NXL2eVqGjb2aD48lY5kV8tQzXbadc4D00R5B91ZXlZWLj4RJmVsl2hR wpg4449tXHDl/6nSXwHiWci4z/erQyFl4npMsuBqRhORwl3g0wB6aDCJvMVygY6ujgfc 6ovg== MIME-Version: 1.0 X-Received: by 10.194.95.195 with SMTP id dm3mr9805999wjb.17.1398967358590; Thu, 01 May 2014 11:02:38 -0700 (PDT) Received: by 10.227.77.10 with HTTP; Thu, 1 May 2014 11:02:38 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130742BDE0@USMBX1.msg.corp.akamai.com> Date: Thu, 1 May 2014 11:02:38 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T1c9qqgMb_ka6H_kU27e-menJrM Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Presentation language parser on github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:02:42 -0000 On 1 May 2014 09:13, Salz, Rich wrote: > There are some minor nits and such that I=E2=80=99ll raise issues for. B= TW, better > to open an issue, make a fix and do a pull request (more learning!) or bo= th? Sorry, couldn't help myself: https://github.com/tlswg/tls13-spec/pull/30 In my experience, the preference order for editorial/minor stuff like this = is: 1. pull request 2. issue 3. email Issues with actual substance are best handled with email, or email+issue if you are certain that it's an issue. If you have a proposal for a fix, a pull request helps, but I often find that it's best to wait until some discussion has happened. From nobody Thu May 1 11:30:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E991A092D for ; Thu, 1 May 2014 11:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIvn9AACK-CO for ; Thu, 1 May 2014 11:30:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2292C1A0919 for ; Thu, 1 May 2014 11:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=808; q=dns/txt; s=iport; t=1398968998; x=1400178598; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Tdee51nODph2j6mR9ZTBYDYsuMrP7DVRbL53XvVcxKs=; b=S/ZiJ2gUUILNltJDPTT62305kF3XREqpauaekqFBAVWFH5k0HwGDCKE+ oc//ftuzgwQZJdV7iBlEz/b5QGWf4UKrP+3cST2Cc6hRjfzGzJkLsdM2z 5ICQtGSfdTLsWwpseCGOGeop1qwMlmCp3nH8kU+EQO0DoxvinwULANITH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMaRYlOtJV2a/2dsb2JhbABagwZPV8VsFnSCLDpRAT5CJwQciDgNlk2zEReRfYEVBJkvkm6DM4Ir X-IronPort-AV: E=Sophos;i="4.97,966,1389744000"; d="scan'208";a="40328082" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 01 May 2014 18:29:56 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s41ITvrU011501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 May 2014 18:29:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 1 May 2014 13:29:56 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Draft Agenda for TLS Interim meeting Thread-Index: AQHPZWtZTWJplrbJPkyJA2kl7TW1zQ== Date: Thu, 1 May 2014 18:29:55 +0000 Message-ID: <22308616-C7DB-4C1B-8DD9-EA65202FDA65@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.224] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LvAOEpzzb0BZtoZS4KUbfwx6_7M Subject: [TLS] Draft Agenda for TLS Interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:30:03 -0000 Draft agenda is posted at http://www.ietf.org/proceedings/interim/2014/05/1= 5/tls/agenda/agenda-interim-2014-tls-1 and copied below: TLS Working Group Interim Meeting Dates/Times:=20 15 May 2014 (9:00 am - 5:00 pm MDT) 16 May 2014 (9:00 am - 2:00 pm MDT) Location: 1899 Wynkoop Street, Suite 600, Denver, CO, USA Day 1 ----------------- 9:00. Get Settled, Administrivia, Agenda (30 min) 9:30 - 10:30 Fixing Session Resumption (Triple Handshake) (60 Min) 10:30 - 12:30 Encrypt SNI or not (120 min)=20 12:30 - 1:30 Lunch 1:30 - 2:00 Wrap up SNI discussion 2:00 - 3:00 Client Puzzles 3:00 - 5:00 Discuss Handshake Flows Day 2 -------------- 9:00 Arrival =20 9:30 - 12:30 Discuss Handshake Flows 12:30 - 1:00 Wrap up Handshake discussion 1:00 - 2:00 Summary and next steps= From nobody Fri May 2 07:13:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCA41A6FF7; Fri, 2 May 2014 07:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U_vlFw12_wb; Fri, 2 May 2014 07:13:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 692E71A2119; Fri, 2 May 2014 07:13:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140502141326.23312.96542.idtracker@ietfa.amsl.com> Date: Fri, 02 May 2014 07:13:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OJSWwNpVXG9oRfVyJh8rdJc0288 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-encrypt-then-mac-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:13:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Encrypt-then-MAC for TLS and DTLS Author : Peter Gutmann Filename : draft-ietf-tls-encrypt-then-mac-01.txt Pages : 8 Date : 2014-05-02 Abstract: This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-encrypt-then-mac-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 2 07:17:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935641A6FBC for ; Fri, 2 May 2014 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAbPXZJSu1yZ for ; Fri, 2 May 2014 07:17:11 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id C3D6C1A6FB4 for ; Fri, 2 May 2014 07:17:10 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 6E0541C211F; Fri, 2 May 2014 16:17:07 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 5618B1FE01CE; Fri, 2 May 2014 16:17:07 +0200 (CEST) Date: Fri, 2 May 2014 16:17:07 +0200 From: Kurt Roeckx To: Fabrice Message-ID: <20140502141707.GA19167@roeckx.be> References: <20140419131019.GA29561@roeckx.be> <20140419195434.GA21513@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140419195434.GA21513@roeckx.be> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fDFE8ha-RCU6SckZXqapOH2alhA Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:17:12 -0000 On Sat, Apr 19, 2014 at 09:54:34PM +0200, Kurt Roeckx wrote: > For stats about servers, see: > https://jve.linuxwall.info/blog/index.php?post/TLS_Survey Here are updated stats: https://lists.fedoraproject.org/pipermail/security/2014-April/001810.html Kurt From nobody Sat May 3 16:32:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71DF1A013D for ; Sat, 3 May 2014 16:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCRsZXB5ZlqX for ; Sat, 3 May 2014 16:32:39 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE551A013B for ; Sat, 3 May 2014 16:32:39 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so5125323wgh.35 for ; Sat, 03 May 2014 16:32:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cAWqGYdFAnpymgbzl71dNRxxe1niXd647sMP0QgMaT4=; b=iVYIQG3ZBdFpiDnM41wZ+JVTajneqh75ZqLSBQsIGqWmVEHDg8Y8KjHo1Ykhf6qX5E nON+yX4c+ff+X7myDKe4/RfAA54ZCWwtRslzMlA6Rljz2aiyjApZxQzNYKvMnW4qpze1 9uk7kS/O7Ru3AU8zcQ/LdbPfipWFMMgBQgT/3GwVhCINIkrL82J7LoExIdieg/hECxEb kVr83UaMz0EeVANGLm++YPSMjyITJPpoOzRsJDes/ExUbclaaSsW25OHBv7pPJHWdYgw 8pnP1X3ai6mR2cZh0JRj3IeGnQVVTVs1/AsK4/GJ2tHIs3x8eMgD14jlAlrG98wlv1/Z inIw== X-Gm-Message-State: ALoCoQl+oyc+O+MkVjTO9ioXybnla/3Ftz+uj4ylHzH1rQGvWla0sq8Ah0p7+PuCXZBoLKsmh11U X-Received: by 10.194.90.107 with SMTP id bv11mr20234006wjb.11.1399159956225; Sat, 03 May 2014 16:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 3 May 2014 16:31:56 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> From: Eric Rescorla Date: Sat, 3 May 2014 16:31:56 -0700 Message-ID: To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=047d7beb9ec02cd52b04f887503d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M5PM-I11b7aWFKCQk-FsBteLNzY Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 23:32:42 -0000 --047d7beb9ec02cd52b04f887503d Content-Type: text/plain; charset=UTF-8 The following pull request is intended to execute this change: https://github.com/tlswg/tls13-spec/pull/37 I'll merge it in on Tuesday. Please let me know before then if this seems substantially wrong. As usual, minor editorial issues can be done by pull requests. Note that we also need to determine a new MTI cipher suite (https://github.com/tlswg/tls13-spec/issues/32) since the previous one uses static RSA. I've left that as a TODO for now. -Ekr On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > The discussion on this list and others supports the consensus in IETF 89 > to remove RSA key transport cipher suites from TLS 1.3. The Editor is > requested to make the appropriate changes to the draft on github. > > More discussion is needed on both DH and ECDH are used going forward and > on if standard DHE parameters will be specified. > > Joe > [For the chairs] > On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) < > jsalowey@cisco.com> wrote: > > > TLS has had cipher suites based on RSA key transport (aka "static RSA", > TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have > several drawbacks including lack of PFS, pre-master secret contributed only > by the client, and the general weakening of RSA over time. It would make > the security analysis simpler to remove this option from TLS 1.3. RSA > certificates would still be allowed, but the key establishment would be via > DHE or ECDHE. The consensus in the room at IETF-89 was to remove RSA key > transport from TLS 1.3. If you have concerns about this decision please > respond on the TLS list by April 11, 2014. > > > > Thanks, > > > > Joe > > [Speaking for the TLS chairs] > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7beb9ec02cd52b04f887503d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The following pull request is intended to execute this cha= nge:


I'll merge it in on Tuesday. Please let me know before then if
this seems substantially wrong. As usual, minor editorial issues
can be done by pull requests.

Note that we also = need to determine a new MTI cipher suite
previous one us= es static RSA. I've left that as a TODO for now.

-Ekr







On Sat, Apr 26, 2014 at 8:24 AM, Joseph Sa= lowey (jsalowey) <jsalowey@cisco.com> wrote:
The discussion on this list and others suppo= rts the consensus in IETF 89 to remove RSA key transport cipher suites from= TLS 1.3. =C2=A0The Editor is requested to make the appropriate changes to = the draft on github.

More discussion is needed on both DH and ECDH are used going forward and on= if standard DHE parameters will be specified.

Joe
[For the chairs]
On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:

> TLS has had cipher suite= s based on RSA key transport (aka "static RSA", TLS_RSA_WITH_*) s= ince the days of SSL 2.0. =C2=A0 These cipher suites have several drawbacks= including lack of PFS, pre-master secret contributed only by the client, a= nd the general weakening of RSA over time. =C2=A0It would make the security= analysis simpler to remove this option from TLS 1.3. =C2=A0RSA certificate= s would still be allowed, but the key establishment would be via DHE or ECD= HE. =C2=A0The consensus in the room at IETF-89 was to remove RSA key transp= ort from TLS 1.3. =C2=A0If you have concerns about this decision please res= pond on the TLS list by April 11, 2014.
>
> Thanks,
>
> Joe
> [Speaking for the TLS chairs]
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7beb9ec02cd52b04f887503d-- From nobody Sun May 4 05:37:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABEA1A0117 for ; Sun, 4 May 2014 05:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv2u2e3pYJAT for ; Sun, 4 May 2014 05:37:23 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id D33421A0062 for ; Sun, 4 May 2014 05:37:22 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so1586650wiw.3 for ; Sun, 04 May 2014 05:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=wQ5dBEacreJF1bW2+mV67XtF6ajLqcm0Fr+XulX13fc=; b=cl33wyTMpAqn7VI99irV3aqdVI+zaYZcx9TYIBjHQfZk51i3kavvuiRA1MirlgVrjV LwqnefsbiMLKBhPOCK/nGH5TBnQHEIz/fNYCaC1MNQsdmjtuC206jsS4hcnSJFNW6kHD OShAk+tygJGrC+lttZxVUCQBjcNDaKzlx+hPUCxA0X3JXTz2Ko+0im0GuVyGPRFL3LDu TMRCBP8gJTOWjZLEhIn+ahnVBzV5fF7bpg13+Ldifb27ahQrTurJXWCVAwZXvLtSsKUO NS/NIBJWBTiJdJC1dnS3o9zvKNGM+L+BKvslexEi5EP+vqCi+cklGRjqG0u1MkmxeRdZ wmQA== X-Received: by 10.180.91.1 with SMTP id ca1mr11479319wib.32.1399207039322; Sun, 04 May 2014 05:37:19 -0700 (PDT) Received: from [172.24.249.242] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h10sm10635369wix.2.2014.05.04.05.37.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 May 2014 05:37:18 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_0A1C53FC-7134-4FCF-9F16-08661343B45A" Date: Sun, 4 May 2014 15:37:18 +0300 References: <20140430100043.15754.90579.idtracker@ietfa.amsl.com> To: "TLS@ietf.org (tls@ietf.org)" Message-Id: <1A46FEB1-3DBB-46F1-BE47-BAA05ACA9135@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fe0EBfPW2gDd9BT5APtHJqIn61E Subject: [TLS] Fwd: New Version Notification for draft-nir-tls-puzzles-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 12:37:24 -0000 --Apple-Mail=_0A1C53FC-7134-4FCF-9F16-08661343B45A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi I=92ve submitted this draft for a method of mitigating DoS and DDoS = attacks using client puzzles. The puzzle in this draft is a partial = break of SHA-256. Comments are welcome. Yoav Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-nir-tls-puzzles-00.txt > Date: April 30, 2014 at 1:00:43 PM GMT+3 > To: Yoav Nir , "Yoav Nir" >=20 >=20 > A new version of I-D, draft-nir-tls-puzzles-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-nir-tls-puzzles > Revision: 00 > Title: Using Client Puzzles to Protect TLS Servers =46rom= Denial of Service Attacks > Document date: 2014-04-29 > Group: Individual Submission > Pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-nir-tls-puzzles-00.txt > Status: = https://datatracker.ietf.org/doc/draft-nir-tls-puzzles/ > Htmlized: http://tools.ietf.org/html/draft-nir-tls-puzzles-00 >=20 >=20 > Abstract: > This document proposes a mechanism for mitigating denial of service > (DoS) and distributed denial of service (DDoS) attacks on TLS > servers. Attackers are limited in their ability to cause resource > waste on the server by requiring proof of work by the client before > these CPU resources are expended. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_0A1C53FC-7134-4FCF-9F16-08661343B45A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi

I=92ve submitted this draft = for a method of mitigating DoS and DDoS attacks using client puzzles. =  The puzzle in this draft is a partial break of = SHA-256.

Comments are = welcome.

Yoav

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = New Version = Notification for draft-nir-tls-puzzles-00.txt
Date: April 30, 2014 at 1:00:43 PM = GMT+3
To: = Yoav Nir <ynir.ietf@gmail.com>, "Yoav = Nir" <ynir.ietf@gmail.com>
=


A new version of I-D, = draft-nir-tls-puzzles-00.txt
has been successfully submitted by Yoav = Nir and posted to the
IETF repository.

Name: = draft-nir-tls-puzzles
Revision: 00
Title: Using = Client Puzzles to Protect TLS Servers =46rom Denial of Service = Attacks
Document date: 2014-04-29
Group: = Individual Submission
Pages: 8
URL: =            = http://www.ietf.org/internet-drafts/draft-nir-tls-puzzles-00.txt
St= atus:         https://d= atatracker.ietf.org/doc/draft-nir-tls-puzzles/
Htmlized: =       http://tools.= ietf.org/html/draft-nir-tls-puzzles-00


Abstract:
=   This document proposes a mechanism for mitigating denial of = service
  (DoS) and distributed denial of service (DDoS) = attacks on TLS
  servers.  Attackers are limited in = their ability to cause resource
  waste on the server by = requiring proof of work by the client before
  these CPU = resources are expended.




Please note that it may take = a couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_0A1C53FC-7134-4FCF-9F16-08661343B45A-- From nobody Sun May 4 16:44:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5601A01D9 for ; Sun, 4 May 2014 16:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9X2NN952DMK for ; Sun, 4 May 2014 16:44:15 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 151841A01D7 for ; Sun, 4 May 2014 16:44:15 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so26284yha.41 for ; Sun, 04 May 2014 16:44:11 -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:content-type; bh=QCCcG2FAETCG4hy4UNCSrpWbrfkP9N3BMB9HShrQJoM=; b=EnZtillS/NvWNCvMK8upd93kxPhb0I+nHZyyuLbSH0yqHsoE8akrACF0hvzVEHIXD/ k8UBLE8a6+7vXOyxoFQlO17dMhWLzPercpvBw+EAu9ORedipC0qg/PqTL8YalpWWIN43 srK0ZFSjbiUnhwTL87ZywCDSdihRwWOMD5595TULam7HikoKKy4iBJf56tctKK2aa/Vl yKUEGhSKjeM4PLO/IIV0Jmn0yXniaElBXfKhEA+cqDnw0MnSC9gRz05jelJvtcGALxKm NkoskNWYsPPYO4r1jzZlmaHPu37YYG9tsXcjfNtHmxPB/Kmfy2ZSEKf+9PpjjWwn0u65 bWbg== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr43251902yhi.83.1399247051737; Sun, 04 May 2014 16:44:11 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 4 May 2014 16:44:11 -0700 (PDT) Date: Sun, 4 May 2014 16:44:11 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0bH2NuQuNUymfPS_t87jRBxNfmQ Subject: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 23:44:16 -0000 Dear all, My impression of the CFRG meeting result was that Curve25519 was fine, and that drafts describing it were going to be written this summer. In TLS we can proceed with this draft it looks like. Am I misremembering/misunderstanding? Sincerely, Watson Ladd From nobody Sun May 4 17:18:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487CD1A0141 for ; Sun, 4 May 2014 17:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf-g4xlGw8tc for ; Sun, 4 May 2014 17:18:24 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 92F901A01DA for ; Sun, 4 May 2014 17:18:24 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so593220wib.1 for ; Sun, 04 May 2014 17:18:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GbB2lvIWZ16yC0V4IrUJzvI9KckcWJVi43Q65DOjwf0=; b=Srn0tYpq64VwAmB9oBWseYP0KKQbVwOCVX0XvH6op0FOfPlTl/sRJhbx0TBareAXeF f/lLVEMLoxl7BcM9zDhFkuJdRJlBXFNArDD8bDjJ2zzX5/fM17QioOcI10YhW0zhSYPK 7nft8aThhjSafZjzMTwkmLDkwPz4hEojlcqILmXLQJMdyWR2dEjiulnwEoqfKWMXQk+V 1rUjHwbMiWapo+dCUUnCnMvXC36CMn4x1Ry4n0y910+1FOfLE792hisrVVen9Aur/9Lu N5j+livDvQfk5Ru4Rvm6sAwzznsnhVwNRFmvSbKlS6j05aSLY0bitngQdoae3toif5yt ny1A== X-Gm-Message-State: ALoCoQkVt0euh4/EMZKzKH+eyp+DWQEcCX8XCv/p2NDPku5bCK1gRsag6K3MTec+VuS5TQEtyBS8 X-Received: by 10.180.94.98 with SMTP id db2mr7696708wib.1.1399249100988; Sun, 04 May 2014 17:18:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 4 May 2014 17:17:40 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 4 May 2014 17:17:40 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d044271409e015e04f89c11b2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f98W_N_RaXQGPg2To7VN9ccdipA Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:18:26 -0000 --f46d044271409e015e04f89c11b2 Content-Type: text/plain; charset=UTF-8 On Sun, May 4, 2014 at 4:44 PM, Watson Ladd wrote: > Dear all, > My impression of the CFRG meeting result was that Curve25519 was fine, > and that drafts describing it were going to be written this summer. In > TLS we can proceed with this draft it looks like. > > Am I misremembering/misunderstanding? > My understanding was a bit more modest, namely that the CFRG intended to produce a recommendation by IETF Toronto and that Curve25519 was probably the leading contender for that recommendation at the 128-bit security level, but that they weren't quite ready to commit. So people were to go off and do drafts with an aim to have an answer by YYZ. Though perhaps I am the one who misunderstood. In either case, as a matter of process I would expect (or at least hope) that the CFRG will send us some sort of formal statement of their recommendation so that we have something specific to refer to for future. -Ekr --f46d044271409e015e04f89c11b2 Content-Type: text/html; charset=UTF-8
On Sun, May 4, 2014 at 4:44 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear all,
My impression of the CFRG meeting result was that Curve25519 was fine,
and that drafts describing it were going to be written this summer. In
TLS we can proceed with this draft it looks like.

Am I misremembering/misunderstanding?

My understanding was a bit more modest, namely that the CFRG intended
to produce a recommendation by IETF Toronto and that Curve25519 was
probably the leading contender for that recommendation at the 128-bit
security level, but that they weren't quite ready to commit. So people were
to go off and do drafts with an aim to have an answer by YYZ. Though
perhaps I am the one who misunderstood.

In either case, as a matter of process I would expect (or at least hope) that
the CFRG will send us some sort of formal statement of their recommendation
so that we have something specific to refer to for future.

-Ekr


--f46d044271409e015e04f89c11b2-- From nobody Sun May 4 17:45:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0011A01DE for ; Sun, 4 May 2014 17:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuy7VMl8jzVg for ; Sun, 4 May 2014 17:45:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 36A651A00E5 for ; Sun, 4 May 2014 17:45:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s450jRd7009360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 May 2014 17:45:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sun, 4 May 2014 17:45:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C97D71F-70E6-4E5F-A58B-A800BB5E5F90@vpnc.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tZ7cC71dxHOzWw8FQs77tH_S9gs Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:45:35 -0000 On May 4, 2014, at 5:17 PM, Eric Rescorla wrote: > My understanding was a bit more modest, namely that the CFRG intended > to produce a recommendation by IETF Toronto and that Curve25519 was > probably the leading contender for that recommendation at the 128-bit > security level, but that they weren't quite ready to commit. So people = were > to go off and do drafts with an aim to have an answer by YYZ. Though > perhaps I am the one who misunderstood. I think you probably were. The way I remember it was that Dave McGrew = asked if anyone had any objections to Curve25519 being the single curve = proposal to the IETF, and there were crickets. I didn't hear any = suggestion that CRFG would make any actual "recommendation". > In either case, as a matter of process I would expect (or at least = hope) that > the CFRG will send us some sort of formal statement of their = recommendation > so that we have something specific to refer to for future. Even if they wanted to, it is still unclear to me how such a thing would = happen formally. If it isn't going to happen formally, there is no = reason to bother trying to force it. To me, this means that anyone who cares about Curve25519 for TLS or = IPsec or S/MIME or SSH should go ahead and start writing drafts. If = somehow the CRFG comes to a different conclusion, you might need to = stop. --Paul Hoffman= From nobody Sun May 4 17:52:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2579E1A01E8 for ; Sun, 4 May 2014 17:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQQ8xMCaLPlo for ; Sun, 4 May 2014 17:52:08 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id BA28A1A01E9 for ; Sun, 4 May 2014 17:52:08 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 19so4705518ykq.36 for ; Sun, 04 May 2014 17:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mZaTXJSyFOvN3TON2VTd7ww7FKUykvZEAEoDW9rblQQ=; b=P7eBc+tq9Ghat7JAZ1SJ5AWvrpHxIKXno0FUMeKEzcfcTsckOKg+9lryRj8XBke0TC p+evrpCPx1lvuqTcdCw+lgGCIcGPnAS2n+jaNK2uvViP3Ct+p1HcuVuJI0uQw6kWUct9 TwAhSPWvG8fufI/7/X+3nJHCrt2ZwWBhB2mSyEZZm5yPJrnDBpkaJZd2uEdBBT6I9okh P7VdFtxlwzIu1/qO6qVWWjkIcxnNOZ/v/rPv1k2K+UTUpzMJplZpbfITY/ppYtzU0cY5 rUwjwwL3M4qF4OiWDx18DAx1NUH5rdmYBpJ1/sD9e0RqACLkOwWJZnfO63+LKfsGusQB Oa1w== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr42873056yhn.87.1399251125438; Sun, 04 May 2014 17:52:05 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 4 May 2014 17:52:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 May 2014 17:52:05 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3bhHVPDHiMc3HO5paYkE8qWNE7Q Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:52:10 -0000 On Sun, May 4, 2014 at 5:17 PM, Eric Rescorla wrote: > On Sun, May 4, 2014 at 4:44 PM, Watson Ladd wrote: >> >> Dear all, >> My impression of the CFRG meeting result was that Curve25519 was fine, >> and that drafts describing it were going to be written this summer. In >> TLS we can proceed with this draft it looks like. >> >> Am I misremembering/misunderstanding? > > > My understanding was a bit more modest, namely that the CFRG intended > to produce a recommendation by IETF Toronto and that Curve25519 was > probably the leading contender for that recommendation at the 128-bit > security level, but that they weren't quite ready to commit. So people were > to go off and do drafts with an aim to have an answer by YYZ. Though > perhaps I am the one who misunderstood. Is this the blocking task? In other words, if the CFRG was to tomorrow say "Curve25519 can be used" would we be ready to proceed to LC? I feel like the answer is "maybe". > > In either case, as a matter of process I would expect (or at least hope) > that > the CFRG will send us some sort of formal statement of their recommendation > so that we have something specific to refer to for future. Well, what's the timeline/scope on this? I got an impression that the document to be produced was an algorithm description, not just a list of curves. Furthermore, we've not discussed signatures, (ECDSA has issues with performance and batch verification, you need Ed25519, not Curve25519 (well, for some variants of not)), so if we want one document to address everything, that's going to be a few more meetings, without really changing the impact for us. Sincerely, Watson Ladd > > -Ekr > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun May 4 17:53:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E861A01EE for ; Sun, 4 May 2014 17:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k24UVYbeILmn for ; Sun, 4 May 2014 17:53:04 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8F31A01EB for ; Sun, 4 May 2014 17:53:03 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so1464740wiv.9 for ; Sun, 04 May 2014 17:53:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5dIdIWx9Iz6tecEnjhdajxh0ts9WuPlUS9C95CSnMcM=; b=eO4XviFXuc7LRYvxHjX1N7cUlT90Cs75wb2qCcyJs+OFPGFEFe2m9pwBBrWZ1Spkpn 8OISww7CKbbpOWWiNtoOtfn15ZgHbH97yOaLNIxKV6fzgGcPUBJyUCUkUFp5UqWLLIJf Hud4FtLGVw4Z9N5kZym9psX8GG59m8K3epw7NVmgNn44I4rIK55oIefo4140MnkvUNZn zqqzVn8WCtb1LsQxIKXvzgwe4S9dvpNAIJA/tRSXUiAiU6+M5BK1itBwkAnxoJFQyh5D mAw3doXIGfv91m4EqeXEln+izr3kVEuw3U8LfJFOJSZ5sqNfZxGoiFdtIi8adH29PObi MmXw== X-Gm-Message-State: ALoCoQk/uvNAtGZpG/JAQTSQCnLVJMh7+E12L8Xm3INbcbJplUad9tgBl2zgsr3J0fVTTFUa7Oq5 X-Received: by 10.194.6.106 with SMTP id z10mr24555469wjz.1.1399251180415; Sun, 04 May 2014 17:53:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 4 May 2014 17:52:20 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <6C97D71F-70E6-4E5F-A58B-A800BB5E5F90@vpnc.org> References: <6C97D71F-70E6-4E5F-A58B-A800BB5E5F90@vpnc.org> From: Eric Rescorla Date: Sun, 4 May 2014 17:52:20 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b3a8b548f86de04f89c8dee Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T6xP32mRc8ZcuA4P6Aa8x1aqleI Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:53:06 -0000 --047d7b3a8b548f86de04f89c8dee Content-Type: text/plain; charset=UTF-8 On Sun, May 4, 2014 at 5:45 PM, Paul Hoffman wrote: > On May 4, 2014, at 5:17 PM, Eric Rescorla wrote: > > > My understanding was a bit more modest, namely that the CFRG intended > > to produce a recommendation by IETF Toronto and that Curve25519 was > > probably the leading contender for that recommendation at the 128-bit > > security level, but that they weren't quite ready to commit. So people > were > > to go off and do drafts with an aim to have an answer by YYZ. Though > > perhaps I am the one who misunderstood. > > I think you probably were. The way I remember it was that Dave McGrew > asked if anyone had any objections to Curve25519 being the single curve > proposal to the IETF, and there were crickets. I didn't hear any suggestion > that CRFG would make any actual "recommendation". If so that makes me sad. I thought the premise of the CFRG curve effort was that they were going to make a recommendation. The TLS chairs will reach out to the CFRG chairs and try to get some clarity on what they propose to do. -Ekr > In either case, as a matter of process I would expect (or at least hope) > that > > the CFRG will send us some sort of formal statement of their > recommendation > > so that we have something specific to refer to for future. > > Even if they wanted to, it is still unclear to me how such a thing would > happen formally. If it isn't going to happen formally, there is no reason > to bother trying to force it. > To me, this means that anyone who cares about Curve25519 for TLS or IPsec > or S/MIME or SSH should go ahead and start writing drafts. If somehow the > CRFG comes to a different conclusion, you might need to stop. > > --Paul Hoffman --047d7b3a8b548f86de04f89c8dee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, May 4, 2014 at 5:45 PM, Paul Hoffman <= paul.hoffman@vpn= c.org> wrote:
On May 4, 2014, at 5:17 PM, = Eric Rescorla <ekr@rtfm.com> wrot= e:

> My understanding was a bit more modest, namely that the CFRG intended<= br> > to produce a recommendation by IETF Toronto and that Curve25519 was > probably the leading contender for that recommendation at the 128-bit<= br> > security level, but that they weren't quite ready to commit. So pe= ople were
> to go off and do drafts with an aim to have an answer by YYZ. Though > perhaps I am the one who misunderstood.

I think you probably were. The way I remember it was that Dave McGrew= asked if anyone had any objections to Curve25519 being the single curve pr= oposal to the IETF, and there were crickets. I didn't hear any suggesti= on that CRFG would make any actual "recommendation".

If so that makes me sad. I thought the premise of the C= FRG curve
effort was that they were going to make a recommendatio= n. The
TLS chairs will reach out to the CFRG chairs and try to ge= t some
clarity on what they propose to do.

-Ekr

> In either case, as a matter of process I would expect (or at least hop= e) that
> the CFRG will send us some sort of formal statement of their recommend= ation
> so that we have something specific to refer to for future.

Even if they wanted to, it is still unclear to me how such a thing wo= uld happen formally. If it isn't going to happen formally, there is no = reason to bother trying to force it.
To me, this means that anyone who cares about Curve25519 for TLS or IPsec o= r S/MIME or SSH should go ahead and start writing drafts. If somehow the CR= FG comes to a different conclusion, you might need to stop.

--Paul Hoffman

--047d7b3a8b548f86de04f89c8dee-- From nobody Sun May 4 18:08:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53E01A01EF for ; Sun, 4 May 2014 18:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKG9-9NWuq7T for ; Sun, 4 May 2014 18:08:07 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) by ietfa.amsl.com (Postfix) with ESMTP id B1B871A017A for ; Sun, 4 May 2014 18:08:07 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id q9so5679425ykb.39 for ; Sun, 04 May 2014 18:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KzNH8d7nJrSpEf2cSiFvqNhUgUQzvvcOIKBQQVZ9IPc=; b=gJmCgVEhDm/xRa2bUuUVHcVmbh7urZCmrEiloKGu94qoaQyccMkgaBgHNwt00aA7oW 46CjqpeRpVDiJEM2rOnQnjSDc6+65PqwmpF0f91Q+0wgvBVSFbM6HofiQzGtxHMo2dW3 B/VSDwS7ZoswqpgfvBBi93V2+rpJKWZYWLWQx0PMWHawfOBazT5B5TJ2Xk43IBSWoDaa MEwDoeWuzfQZwQphnsGCtd7VA/H01TrLqDcA4UA9AwswkZjJhWZaleIJSw4IXJXnGgvZ ygjsX0XXiew0cJGP+yhFpdc6KQi7mDww1ypNZHWgarhbytHfNlCNScH8NOq+Mo/ke01w g/AQ== MIME-Version: 1.0 X-Received: by 10.236.46.225 with SMTP id r61mr6292975yhb.107.1399252084427; Sun, 04 May 2014 18:08:04 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 4 May 2014 18:08:04 -0700 (PDT) In-Reply-To: <22308616-C7DB-4C1B-8DD9-EA65202FDA65@cisco.com> References: <22308616-C7DB-4C1B-8DD9-EA65202FDA65@cisco.com> Date: Sun, 4 May 2014 18:08:04 -0700 Message-ID: From: Watson Ladd To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Kz2UADwdZio2BqU687YkcYRD-yA Cc: "" Subject: Re: [TLS] Draft Agenda for TLS Interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 01:08:12 -0000 On Thu, May 1, 2014 at 11:29 AM, Joseph Salowey (jsalowey) wrote: > Draft agenda is posted at http://www.ietf.org/proceedings/interim/2014/05/15/tls/agenda/agenda-interim-2014-tls-1 and copied below: > > TLS Working Group Interim Meeting > Dates/Times: > 15 May 2014 (9:00 am - 5:00 pm MDT) > 16 May 2014 (9:00 am - 2:00 pm MDT) > Location: > 1899 Wynkoop Street, Suite 600, Denver, CO, USA > > > Day 1 > ----------------- > 9:00. Get Settled, Administrivia, Agenda (30 min) > 9:30 - 10:30 Fixing Session Resumption (Triple Handshake) (60 Min) > 10:30 - 12:30 Encrypt SNI or not (120 min) > 12:30 - 1:30 Lunch > 1:30 - 2:00 Wrap up SNI discussion > 2:00 - 3:00 Client Puzzles > 3:00 - 5:00 Discuss Handshake Flows > > Day 2 > -------------- > 9:00 Arrival > 9:30 - 12:30 Discuss Handshake Flows > 12:30 - 1:00 Wrap up Handshake discussion > 1:00 - 2:00 Summary and next steps So I unfortunately won't be at the meeting. I do wonder about the scope: are Session Resumption fixes and Client Puzzles for TLS 1.2 and prior, or only TLS 1.3? If we are discussing them in the context of TLS 1.3 then session resumption fixes aren't really a good idea, depending on how much you want to break. If you want to break backwards compatibility, then you take a known-good key exchange and use that. If TLS 1.3 is really TLS 1.2.1: that is TLS 1.2 with some new extensions added and some options removed, then patching makes some sense. However, I don't understand how patching a protocol when you can do a real fix is a good idea, and so why discuss a particular attack, when you can rule them all out by making a few simple changes? (There are good arguments on both sides. Encrypting SNI is likely to be a break of compatibility, as is Finished changes for analysis improvements, and cleaning the protocol in general. But breaking compatibility will slow adoption, and at this point we need significant adoption of fixes to TLS and workarounds to security issues. We've also got the general "well, what you really do isn't in the spec" problem, which makes it difficult to see what's going on) Sincerely, Watson Ladd From nobody Sun May 4 18:21:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495271A01EF for ; Sun, 4 May 2014 18:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSHxlFug_T6v for ; Sun, 4 May 2014 18:21:49 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 64AB81A01E1 for ; Sun, 4 May 2014 18:21:49 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so320472wes.4 for ; Sun, 04 May 2014 18:21:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PYypceLk6Uq/LGXoQJRG5i+gA2JpBTWFFyCHFNisaD0=; b=eI5+h3tTc97pLXSuN0DrcNsydhSiACTv/vP60RrUndwrN5KHEn6jdsPIZNt4D/hdw9 vHjnkLRToOqcNo9MwEi2RqMBa9ufpmtRhkHoOVjp1VRfRmGdhkdAXkweC9T4jUtriQUr BBI1pS1WnDs6YTGsdT8XeKxVb8GWkSg/EVT5R8Prby1qVRIRbNz5X3b7tOOygPg87Gyv 5Z29xfqK+xw6PvB/hhD32kAwjzK0Zo5NyURUEgY4xjDcr/0cy2NEm1xbZShq3TqJezTA gELaC2aoYeXHhu4DGmoax69gXW0X4DKd3MwXU+CG7WSEWRbgRMXZJ7/7OihIhcg7W0bE G7Lw== X-Gm-Message-State: ALoCoQl4y2PBC67K6uH6G4jIwtsuUA8lhEGF5lBaipLxAG0spGgBKvdal95/V0MKHHMsWXPGm+KB X-Received: by 10.180.212.48 with SMTP id nh16mr13248630wic.49.1399252905732; Sun, 04 May 2014 18:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 4 May 2014 18:21:05 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <22308616-C7DB-4C1B-8DD9-EA65202FDA65@cisco.com> From: Eric Rescorla Date: Sun, 4 May 2014 18:21:05 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c3510265b22104f89cf4da Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1mB5e0jlMTExZX5P6CtE9m9bYHw Cc: "" Subject: Re: [TLS] Draft Agenda for TLS Interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 01:21:51 -0000 --001a11c3510265b22104f89cf4da Content-Type: text/plain; charset=UTF-8 On Sun, May 4, 2014 at 6:08 PM, Watson Ladd wrote: > On Thu, May 1, 2014 at 11:29 AM, Joseph Salowey (jsalowey) > wrote: > > Draft agenda is posted at > http://www.ietf.org/proceedings/interim/2014/05/15/tls/agenda/agenda-interim-2014-tls-1and copied below: > > > > TLS Working Group Interim Meeting > > Dates/Times: > > 15 May 2014 (9:00 am - 5:00 pm MDT) > > 16 May 2014 (9:00 am - 2:00 pm MDT) > > Location: > > 1899 Wynkoop Street, Suite 600, Denver, CO, USA > > > > > > Day 1 > > ----------------- > > 9:00. Get Settled, Administrivia, Agenda (30 min) > > 9:30 - 10:30 Fixing Session Resumption (Triple Handshake) (60 Min) > > 10:30 - 12:30 Encrypt SNI or not (120 min) > > 12:30 - 1:30 Lunch > > 1:30 - 2:00 Wrap up SNI discussion > > 2:00 - 3:00 Client Puzzles > > 3:00 - 5:00 Discuss Handshake Flows > > > > Day 2 > > -------------- > > 9:00 Arrival > > 9:30 - 12:30 Discuss Handshake Flows > > 12:30 - 1:00 Wrap up Handshake discussion > > 1:00 - 2:00 Summary and next steps > > So I unfortunately won't be at the meeting. I do wonder about the > scope: are Session Resumption fixes and Client Puzzles for TLS 1.2 and > prior, or only TLS 1.3? The intention is to discuss Session Resumption fixes in the context of TLS <1.3 as well, since presumably we want people to have security against triple handshake attacks even if they don't want to upgrade to the latest version of TLS (no matter how advisable that might otherwise be.) Since it's not clear we're going to do client puzzles at all I think it's probably premature to say which version we might or might not do them in. -Ekr --001a11c3510265b22104f89cf4da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, May 4, 2014 at 6:08 PM, Watson Ladd <<= a href=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail= .com> wrote:
On Thu, May 1, 2014 at 11:29 AM, Joseph= Salowey (jsalowey)
<jsalowey@cisco.= com> wrote:
> Draft agenda is posted at h= ttp://www.ietf.org/proceedings/interim/2014/05/15/tls/agenda/agenda-interim= -2014-tls-1 and copied below:
>
> TLS Working Group Interim Meeting
> Dates/Times:
> 15 May 2014 (9:00 am - 5:00 pm MDT)
> 16 May 2014 (9:00 am - 2:00 pm MDT)
> Location:
> 1899 Wynkoop Street, Suite 600, Denver, CO, USA
>
>
> Day 1
> -----------------
> 9:00. Get Settled, Administrivia, Agenda (30 min)
> 9:30 - 10:30 =C2=A0Fixing Session Resumption (Triple Handshake) (60 Mi= n)
> 10:30 - 12:30 Encrypt SNI or not (120 min)
> 12:30 - 1:30 Lunch
> 1:30 - 2:00 =C2=A0Wrap up SNI discussion
> 2:00 - 3:00 =C2=A0Client Puzzles
> 3:00 - 5:00 =C2=A0Discuss Handshake Flows
>
> Day 2
> --------------
> 9:00 Arrival
> 9:30 - 12:30 Discuss Handshake Flows
> 12:30 - 1:00 =C2=A0Wrap up Handshake discussion
> 1:00 - 2:00 =C2=A0Summary and next steps

So I unfortunately won't be at the meeting. I do wonder about the=
scope: are Session Resumption fixes and Client Puzzles for TLS 1.2 and
prior, or only TLS 1.3?

The intention is to= discuss Session Resumption fixes in the context of
TLS <1.3 a= s well, since presumably we want people to have security
against = triple handshake attacks even if they don't want to upgrade to
the latest version of TLS (no matter how advisable that might otherwis= e
be.)

Since it's not clear we'r= e going to do client puzzles at all I think it's
probably pre= mature to say which version we might or might not do them
in.

-Ekr



=C2=A0
=C2=A0

--001a11c3510265b22104f89cf4da-- From nobody Sun May 4 18:45:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5D61A01FA for ; Sun, 4 May 2014 18:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3cKcBxydEY6 for ; Sun, 4 May 2014 18:45:20 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 285FC1A01FF for ; Sun, 4 May 2014 18:45:19 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4ECF328501; Mon, 5 May 2014 01:45:16 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3B6A028500; Mon, 5 May 2014 01:45:16 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 26ECC2027; Mon, 5 May 2014 01:45:16 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sun, 4 May 2014 21:45:15 -0400 From: "Salz, Rich" To: Eric Rescorla , Paul Hoffman Date: Sun, 4 May 2014 21:45:14 -0400 Thread-Topic: [TLS] Curve25519 draft Thread-Index: Ac9n/GIoU2jD2j9nTwu01WanJTxq6AAByDcA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7D@USMBX1.msg.corp.akamai.com> References: <6C97D71F-70E6-4E5F-A58B-A800BB5E5F90@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7DUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CRo58Kl03JE221VUuYXWfkZbkkI Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 01:45:21 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7DUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgcmVjb2xsZWN0aW9uIGlzIHRoYXQgc2luY2UgdGhlcmUgd2VyZSBubyBvYmplY3Rpb25zLCBT ZWFuIHdhcyBnb2luZyB0byB3cml0ZSBhIGRvYywgSSB3b3VsZCBoZWxwIGFuZCBUYW5qYSB3b3Vs ZCByZXZpZXcgaXQgYW5kIGl0IHdvdWxkIGVub3VnaCBpbXBsZW1lbnRhdGlvbiBhbmQgc2VjdXJp dHkgYmFja2dyb3VuZCB0byBiZSAqdGhlKiByZWNvbW1lbmRhdGlvbi4NCg0KLS0NClByaW5jaXBh bCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ2llcywgQ2FtYnJpZGdlLCBNQQ0K SU06IHJzYWx6QGphYmJlci5tZTxtYWlsdG86cnNhbHpAamFiYmVyLm1lPjsgVHdpdHRlcjogUmlj aFNhbHoNCg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7DUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZs aW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5NeSByZWNvbGxlY3Rpb24gaXMgdGhhdCBzaW5jZSB0aGVyZSB3 ZXJlIG5vIG9iamVjdGlvbnMsIFNlYW4gd2FzIGdvaW5nIHRvIHdyaXRlIGEgZG9jLCBJIHdvdWxk IGhlbHAgYW5kIFRhbmphIHdvdWxkIHJldmlldyBpdCBhbmQgaXQgd291bGQgZW5vdWdoIGltcGxl bWVudGF0aW9uIGFuZCBzZWN1cml0eSBiYWNrZ3JvdW5kIHRvIGJlICo8Yj50aGU8L2I+KiByZWNv bW1lbmRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0twqAgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByaW5jaXBhbCBTZWN1 cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5Ba2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPklNOiA8YSBocmVmPSJtYWlsdG86cnNhbHpAamFiYmVyLm1lIj48c3BhbiBzdHlsZT0nY29s b3I6Ymx1ZSc+cnNhbHpAamFiYmVyLm1lPC9zcGFuPjwvYT47IFR3aXR0ZXI6IFJpY2hTYWx6PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7DUSMBX1msgcorp_-- From nobody Sun May 4 20:20:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B95F1A0231 for ; Sun, 4 May 2014 20:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ozykt-JbRcWl for ; Sun, 4 May 2014 20:20:13 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 163071A0230 for ; Sun, 4 May 2014 20:20:13 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so1850305yho.29 for ; Sun, 04 May 2014 20:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tPW9drsNySxsXeazSq6ikylcoopeAVU7Pvo/qgVZscA=; b=vnD/m+0+dtyP28QgoalIJEOM9AY2sPGGX9fEql4ykCzUly05ZEvq8NFqgan0hqQZWo 6xYceij1uEVY7WfrYWNkW5yCdN8YJl95eH4sug6uYheYOHsO72Ws6Tqm4PRMzspgyhCU DzFep3qwozgIOARJhzfKhzXpExU69BGHpFjKVVhpV5dqQzrXFQiVx+J7aM0dyD263QMq 6KW28DkDv6BeTsleLPX9Ctl9sGBfRSinGANC/6n2lyt3IHvWTjBShOOrQUl9Ya0KGxG8 6cFTgzJb/nxxdDb+0KPyd8Sgd8V+0bJ0mp8B+8O5i94yKFr0d9Jb/VrXWZrfCFvJ9afp 7ycw== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr44842737yhh.66.1399260009792; Sun, 04 May 2014 20:20:09 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 4 May 2014 20:20:09 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7D@USMBX1.msg.corp.akamai.com> References: <6C97D71F-70E6-4E5F-A58B-A800BB5E5F90@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C71307F9FA7D@USMBX1.msg.corp.akamai.com> Date: Sun, 4 May 2014 20:20:09 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/szrJfO_aj17jieS7JMIRpkcnJcM Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] Curve25519 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 03:20:16 -0000 On Sun, May 4, 2014 at 6:45 PM, Salz, Rich wrote: > My recollection is that since there were no objections, Sean was going to > write a doc, I would help and Tanja would review it and it would enough > implementation and security background to be *the* recommendation. Yes, that's my impression also. So is there any reason to wait for that doc to come out before proceeding with the 25519 in TLS draft? Sincerely, Watson Ladd > > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge, MA > > IM: rsalz@jabber.me; Twitter: RichSalz > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon May 5 00:28:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D21A027E for ; Mon, 5 May 2014 00:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zy0s3jsoD7R for ; Mon, 5 May 2014 00:28:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC581A0019 for ; Mon, 5 May 2014 00:28:34 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s457SQpg028759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 5 May 2014 03:28:26 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s457SNhu006039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 May 2014 03:28:25 -0400 Message-ID: <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Mon, 05 May 2014 09:28:23 +0200 In-Reply-To: References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hw56ad8QncJZ0TToC7sb3wx2xZ8 Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 07:28:35 -0000 On Sat, 2014-05-03 at 16:31 -0700, Eric Rescorla wrote: > The following pull request is intended to execute this change: > > https://github.com/tlswg/tls13-spec/pull/37 > I'll merge it in on Tuesday. Please let me know before then if > this seems substantially wrong. As usual, minor editorial issues > can be done by pull requests. Shouldn't such a change depend on a fix to the compatibility issues present in the DHE ciphersuites? Otherwise it just makes ECDHE the only key exchange in TLS that can be made compatible with random peers. Elliptic curves are good, but it would be nice to have non-ECC key exchanges as well. regards, Nikos From nobody Mon May 5 10:00:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0081A03F0 for ; Mon, 5 May 2014 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8T_3A88XfxX for ; Mon, 5 May 2014 10:00:35 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id E7D931A037A for ; Mon, 5 May 2014 10:00:34 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 0D1381C2069; Mon, 5 May 2014 19:00:30 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id D27DD1FE0251; Mon, 5 May 2014 19:00:29 +0200 (CEST) Date: Mon, 5 May 2014 19:00:29 +0200 From: Kurt Roeckx To: Nikos Mavrogiannopoulos Message-ID: <20140505170029.GA24821@roeckx.be> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kuaoK1VOtomMpRpWB9ARB0Dmg4A Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:00:40 -0000 On Mon, May 05, 2014 at 09:28:23AM +0200, Nikos Mavrogiannopoulos wrote: > On Sat, 2014-05-03 at 16:31 -0700, Eric Rescorla wrote: > > The following pull request is intended to execute this change: > > > > https://github.com/tlswg/tls13-spec/pull/37 > > I'll merge it in on Tuesday. Please let me know before then if > > this seems substantially wrong. As usual, minor editorial issues > > can be done by pull requests. > > Shouldn't such a change depend on a fix to the compatibility issues > present in the DHE ciphersuites? Otherwise it just makes ECDHE the only > key exchange in TLS that can be made compatible with random peers. > > Elliptic curves are good, but it would be nice to have non-ECC key > exchanges as well. I was under the impression that there was also a proposal to use known DHE primes so that there is no requirment to verify them. I'm not sure this is written down somewhere, but I think that we only want to use things where the verification is very simple. Kurt From nobody Mon May 5 10:24:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04E1A03C8 for ; Mon, 5 May 2014 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWfgJ7ayagly for ; Mon, 5 May 2014 10:24:22 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1111A00D7 for ; Mon, 5 May 2014 10:24:21 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so1653634wgg.21 for ; Mon, 05 May 2014 10:24:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/COPIS6+lY7cHX9kFDKNKxxPQY/lBb2W0vr9nh2/w+s=; b=K+3jMZpTc/dBo56x9zz9jZAac/dhEL9ADr2DJ/PPa7IWABUosirjI1V4Gan8bdTrSY s3WoutTdL3GZXxEdfS13HW3g3EQ1k8RaXXLBN0R5HtE59csi+RFxVlIa9N6e6y1PBTRH sln318Mcw4Vqx34ZM+ajhdD12WtCwaGEp+vrAU+yvr2Q56XJDoraEe3dutk7pj4xp7m3 YLTYGzIjqFi+v+boYpwLFvqslkjENu6FsqDExCYapAhBhHVB2wAygCRp/5eKkA8lKG2T 2iB2X7JJiAcUZRD3vaJQj1ZaSyf5tC/NdnYQ/FVXbfuQJCP3otLGnX00l6k/DAxCrfeP sA4w== X-Gm-Message-State: ALoCoQnZb6xN9T8pLdUVQh+AAzuQqJZEs1dWG/PxhobvVWm9y5KlMk0p3JuankCtAJJ2RagUoH/q X-Received: by 10.194.109.68 with SMTP id hq4mr9540642wjb.21.1399310658101; Mon, 05 May 2014 10:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 5 May 2014 10:23:37 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <20140505170029.GA24821@roeckx.be> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> From: Eric Rescorla Date: Mon, 5 May 2014 10:23:37 -0700 Message-ID: To: Kurt Roeckx Content-Type: multipart/alternative; boundary=e89a8ff1cdb4b4fb3c04f8aa6619 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xW0xVI1wCPB2_tr7a9AnwE4xWEs Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:24:24 -0000 --e89a8ff1cdb4b4fb3c04f8aa6619 Content-Type: text/plain; charset=UTF-8 You're probably thinking of: http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 This seems like a reasonable kind of thing for the WG to consider, but my impression was that the WG consensus was to remove static RSA unconditionally. Certainly, it would be reasonable to argue that we should address this issue prior to final publication, however. -Ekr On Mon, May 5, 2014 at 10:00 AM, Kurt Roeckx wrote: > On Mon, May 05, 2014 at 09:28:23AM +0200, Nikos Mavrogiannopoulos wrote: > > On Sat, 2014-05-03 at 16:31 -0700, Eric Rescorla wrote: > > > The following pull request is intended to execute this change: > > > > > > https://github.com/tlswg/tls13-spec/pull/37 > > > I'll merge it in on Tuesday. Please let me know before then if > > > this seems substantially wrong. As usual, minor editorial issues > > > can be done by pull requests. > > > > Shouldn't such a change depend on a fix to the compatibility issues > > present in the DHE ciphersuites? Otherwise it just makes ECDHE the only > > key exchange in TLS that can be made compatible with random peers. > > > > Elliptic curves are good, but it would be nice to have non-ECC key > > exchanges as well. > > I was under the impression that there was also a proposal to use > known DHE primes so that there is no requirment to verify them. > > I'm not sure this is written down somewhere, but I think that we > only want to use things where the verification is very simple. > > > Kurt > > --e89a8ff1cdb4b4fb3c04f8aa6619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're probably thinking of:

This seems like a reasonable kind of thing for the WG to
consider, but my impression was that the WG consensus
was = to remove static RSA unconditionally. Certainly, it would
be reas= onable to argue that we should address this issue prior
to final publication, however.

-Ekr



On= Mon, May 5, 2014 at 10:00 AM, Kurt Roeckx <kurt@roeckx.be> wro= te:
On Mon, May 05, 2014 at 09:28:23AM= +0200, Nikos Mavrogiannopoulos wrote:
> On Sat, 2014-05-03 at 16:31 -0700, Eric Rescorla wrote:
> > The following pull request is intended to execute this change: > >
> > https://github.com/tlswg/tls13-spec/pull/37
> > I'll merge it in on Tuesday. Please let me know before then i= f
> > this seems substantially wrong. As usual, minor editorial issues<= br> > > can be done by pull requests.
>
> Shouldn't such a change depend on a fix to the compatibility issue= s
> present in the DHE ciphersuites? Otherwise it just makes ECDHE the onl= y
> key exchange in TLS that can be made compatible with random peers.
>
> Elliptic curves are good, but it would be nice to have non-ECC key
> exchanges as well.

I was under the impression that there was also a proposal to us= e
known DHE primes so that there is no requirment to verify them.

I'm not sure this is written down somewhere, but I think that we
only want to use things where the verification is very simple.


Kurt


--e89a8ff1cdb4b4fb3c04f8aa6619-- From nobody Mon May 5 10:25:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7513F1A038A for ; Mon, 5 May 2014 10:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPabbHsi_npa for ; Mon, 5 May 2014 10:25:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8876A1A01BB for ; Mon, 5 May 2014 10:25:49 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B5FD9F984; Mon, 5 May 2014 13:25:43 -0400 (EDT) Message-ID: <5367C98A.3000200@fifthhorseman.net> Date: Mon, 05 May 2014 13:25:30 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos , Eric Rescorla References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d1IuVtP9XmtBk0CGr7jQXO6VFj9xxvG8c" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/B8Jyl4KLZgqLP3mhDkVl6uN4qZ0 Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:25:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d1IuVtP9XmtBk0CGr7jQXO6VFj9xxvG8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2014 03:28 AM, Nikos Mavrogiannopoulos wrote: > Shouldn't such a change depend on a fix to the compatibility issues > present in the DHE ciphersuites? Otherwise it just makes ECDHE the only= > key exchange in TLS that can be made compatible with random peers. >=20 > Elliptic curves are good, but it would be nice to have non-ECC key > exchanges as well. I agree with this sentiment, and hope that folks will review my proposal for improvements to the discrete log DHE key exchange: https://datatracker.ietf.org/doc/draft-gillmor-tls-negotiated-dl-dhe/ If you're thinking of other compatibility issues with DHE ciphersuites aren't covered by that draft, please let me know, i'd like to try to improve the situation. I would be happy to have the draft worked on by this WG if people here think it's useful to the protocol. (note also that these improvements to DL-DHE do not need to wait until TLS 1.3 to be useful) --dkg --d1IuVtP9XmtBk0CGr7jQXO6VFj9xxvG8c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTZ8mKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcsDkP/jkWkuJUL02SGFoz3dyu8Hur P4K7BWs7qlarj/c0s96BMNPKv2iwI7hc1qcdqXfLDb/8V2IC9qNmaYuH3LaKh3YN naaLWVJAyIOeg2MiOi/7z6JQMw08Hx/O2jWiG6P+H5MbnGT0+u1LDZKGaoJk9FDg vizX3WUMu6ImM0hG9MCcHKYNhGua68owzt3bwx3GJW0xFPmrk1sQgeYy/lLciOmK a7yD9QIgcDyoWcR2jmCOUk2hVpnr9A5lqgWRpWGB8uOAbP6/Z7Xq1uOZ4mT03vWx HULjAEYC32wpc2NKi/MvB/chhzob9WFZJXPVLlV6qPNIRlsb9go9UiNES75hjBR8 0f67J/3Jx6stW8Aru0D9EC5gltM8xawddrk045SbvmdMJsveN0QmGinIYAXWo13J RQNTZQnetldEw1lsQsa6NQBtoTJ38bB9KasW6YeticLqnYf9FNvcNNFuSsz+AEM/ X20Po6kVlPQ4KL0G5oiAlbig3hN1WuwUliWbRcZ7yl98NB+rLmEcxDfoXLUwIHC0 bTLTh0EiMtpeQGc5K+uZFIs26wblhbmeigVzNnbfMLsMd2FFjN7Q6HHY3WRpnL7n KAhjjGBrYBLXKCkzd12XSUZHXKCERmpfSP7aHeFxDQjtYY5wwIn9uKUYhLwVwNf1 SmGSf7XlE6PApOJL9iKr =LquS -----END PGP SIGNATURE----- --d1IuVtP9XmtBk0CGr7jQXO6VFj9xxvG8c-- From nobody Mon May 5 10:46:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63811A0416 for ; Mon, 5 May 2014 10:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eiZDbndG2PY for ; Mon, 5 May 2014 10:46:19 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 47BF31A0411 for ; Mon, 5 May 2014 10:46:19 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 572431C2069; Mon, 5 May 2014 19:46:15 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 33B471FE0251; Mon, 5 May 2014 19:46:15 +0200 (CEST) Date: Mon, 5 May 2014 19:46:14 +0200 From: Kurt Roeckx To: Eric Rescorla Message-ID: <20140505174614.GA26839@roeckx.be> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ap-IuvG3EmYI3Wrk79TgV5S9_uU Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:46:20 -0000 On Mon, May 05, 2014 at 10:23:37AM -0700, Eric Rescorla wrote: > You're probably thinking of: > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > > This seems like a reasonable kind of thing for the WG to > consider, but my impression was that the WG consensus > was to remove static RSA unconditionally. Certainly, it would > be reasonable to argue that we should address this issue prior > to final publication, however. I'm not sure what you mean with "static RSA". It's my understanding that this proposal is about removing the RSA key exchange and only using something like DHE and ECDHE. That draft would still be valid and useful if RSA key exchanges are dropped. Kurt From nobody Mon May 5 10:49:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741291A041E for ; Mon, 5 May 2014 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4NySKGe4Saq for ; Mon, 5 May 2014 10:49:35 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 669C81A041C for ; Mon, 5 May 2014 10:49:35 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so5956271wgh.5 for ; Mon, 05 May 2014 10:49:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QmcU4O4AGZtnGbOOJlrgfCLBwxzQH2YjOC5HWCWulKI=; b=ezMF5ywZ2s6y/XMCwjuCMVfBCqDPsVSADhvsdSvetwg02YSZSbJXSzmj317r0gymJ/ sF8yGtjq0TxBMf9/7KXZpsenX1uhVcEfMJ4MUjYF4Q5+3jVFRKguqIvfM/GVTuPdAszL 5NYPoY5rnmT7Phx87tr/BKRXm3abE4dr3EXtKesqdwprE2SSJoy28HidXYHnHc85zrk/ 7IcSteeipe0hUCr/chuENyTzZrsJIa0PW7r5kK4DgjTiYifH9eQPQ82WYM6azYaAd4I3 68OOqtKH0kfnQ53RyHR83KZCF/VCl9C5bGp2Fd8WePZKn7h4I01i/A7/6Ct7K/K49QNW R7lA== X-Gm-Message-State: ALoCoQkBTCWja/ckcBf1g75bWdQcBf4qf+rvkkQ4Z1KBbqwWlalFKpv1BFmWqCZEoY1yF3cHRz2A X-Received: by 10.194.187.107 with SMTP id fr11mr2857955wjc.70.1399312171520; Mon, 05 May 2014 10:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 5 May 2014 10:48:51 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <20140505174614.GA26839@roeckx.be> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> <20140505174614.GA26839@roeckx.be> From: Eric Rescorla Date: Mon, 5 May 2014 10:48:51 -0700 Message-ID: To: Kurt Roeckx Content-Type: multipart/alternative; boundary=047d7bb03f60e9e18904f8aac0af Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VhE6pe_I9FMp4ks1QW2l355JEnA Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:49:38 -0000 --047d7bb03f60e9e18904f8aac0af Content-Type: text/plain; charset=UTF-8 On Mon, May 5, 2014 at 10:46 AM, Kurt Roeckx wrote: > On Mon, May 05, 2014 at 10:23:37AM -0700, Eric Rescorla wrote: > > You're probably thinking of: > > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > > > > This seems like a reasonable kind of thing for the WG to > > consider, but my impression was that the WG consensus > > was to remove static RSA unconditionally. Certainly, it would > > be reasonable to argue that we should address this issue prior > > to final publication, however. > > I'm not sure what you mean with "static RSA". It's my > understanding that this proposal is about removing the RSA key > exchange and only using something like DHE and ECDHE. Correct. I mean "RSA key exchange". My point was that my impression of WG consensus was that we were to remove RSA key exchange regardless of the fate of Daniel's draft. > That draft > would still be valid and useful if RSA key exchanges are dropped. Yes, I agree. I'm merely saying that I don't think it's a precondition to merging this pull request. -Ekr > > > Kurt > > --047d7bb03f60e9e18904f8aac0af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 5, 2014 at 10:46 AM, Kurt Roeckx <= kurt@roeckx.be><= /span> wrote:
On Mon, May 05, 2014 at 10:2= 3:37AM -0700, Eric Rescorla wrote:
> You're probably thinking of:
> http://tools.ietf.org/html/draft-gillmor-tls-nego= tiated-dl-dhe-02
>
> This seems like a reasonable kind of thing for the WG to
> consider, but my impression was that the WG consensus
> was to remove static RSA unconditionally. Certainly, it would
> be reasonable to argue that we should address this issue prior
> to final publication, however.

I'm not sure what you mean with "static RSA". =C2=A0It&= #39;s my
understanding that this proposal is about removing the RSA key
exchange and only using something like DHE and ECDHE.

=
Correct. I mean "RSA key exchange". My point was that = my impression of
WG consensus was that we were to remove RSA key = exchange regardless
of the fate of Daniel's draft.

=C2=A0
=C2=A0That draft
would still be valid and useful if RSA key exchanges are dropped.

Yes, I agree. I'm merely saying that I don't= think it's a precondition to
merging this pull request.

-Ekr
=C2=A0


Kurt


--047d7bb03f60e9e18904f8aac0af-- From nobody Mon May 5 11:43:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3419F1A0424 for ; Mon, 5 May 2014 11:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi6-WdOceLws for ; Mon, 5 May 2014 11:43:52 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by ietfa.amsl.com (Postfix) with ESMTP id 664C01A0401 for ; Mon, 5 May 2014 11:43:52 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so5068160qgd.19 for ; Mon, 05 May 2014 11:43:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LFo3WXfXoV5m1KPDzk7xtH4xeaD349cAPH60rXimiVY=; b=Ka7lWIPWSZNPSYmYS1e5EJNNlMscRJsnSwXbpCecJd1DoQOw6Qo9znDCwfUTIJObg2 JQNHRuG6IfVu89BWl+N1Hf7l1bK0A3k7kjkw4rMWsBE7lVSl2QSgieCm5UFZ+ag1G57m Ti2DrIng+NptsPc7pNVJmNy3lFxRulPFAChcToAYCGb3A4yNyS8jrX8ib9RI8ZxHH22I W+8suzeadaPl/q/8HzSvrVhUZLYSDCJJEb+JDlx1K0lSFFexzr4vXlSrHLMv/W8vbeEJ 2TO7SKOqAkDwVHuXcxsJFgZb/FoN1rWClaln9EgcYFMwQEOigzCaHIyuRN+h3ZkPe7PN nXeg== X-Gm-Message-State: ALoCoQmPYV/MD8ECymH8ii9DP5MW+u4TGzPPYCs9j2d9Qg6CCBihoojjuIrISLXMO6D7R0MGJSEu X-Received: by 10.224.172.2 with SMTP id j2mr48207478qaz.83.1399315428781; Mon, 05 May 2014 11:43:48 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 21sm12383317qgh.23.2014.05.05.11.43.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 11:43:48 -0700 (PDT) Message-ID: <5367DBEB.7030802@nthpermutation.com> Date: Mon, 05 May 2014 14:43:55 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> In-Reply-To: <535FE558.2090306@nthpermutation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nfeDFk6xE4B0gx_-2Rk3kxcQFfs Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:43:54 -0000 I never got an answer or response on the following. Mike On 4/29/2014 1:46 PM, Michael StJohns wrote: > On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote: >> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use >> record layer protection of type AEAD. The Editor is requested to make >> the appropriate changes to the draft on github. > > Sorry - I'm coming late here. Does this also imply the complete > elimination of the integrity only cipher suites? > > With respect to the AEAD approach and with respect to composited AEAD > cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per > Guttman for example), does this also imply that the key expansion > phase will never be used to generate MAC keys, and that the cipher > suite has to provide whatever mechanisms that are required to split > the AEAD key into underlying encryption/integrity keys if required? > > Next (reading from the commited editors copy), this refers to 5116 > which uses a one-size fits all approach that doesn't really fit all > sizes, especially for composited AEAD. E.g. the draft describes this > generally as an incrementing value. For AEAD suites that comply with > 5116, that should be part of the suite specification - not TLS. For > TLS, this just needs to be an normatively opaque, per-message > field. Instead, place an Informative section which recommends how > to do this with AEAD suites that currently exist. > > And finally, as I've noted many times before, deriving IV/nonce > material from the master_secret at the same time as deriving keys is > not securely supportable in hardware. > >> >> Joe >> [For the chairs] >> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) >> wrote: >> >>> TLS has supported a number of different cipher types for protecting >>> the record layer. In TLS 1.3 these include Stream Cipher, CBC >>> Block Cipher and AEAD Cipher. The construction of the CBC mode >>> within TLS has been shown to be flawed and stream ciphers are not >>> generally applicable to DTLS. Using a single mechanism for >>> cryptographic transforms would make security analysis easier. AEAD >>> ciphers can be constructed from stream ciphers and block ciphers and >>> are defined as protocol independent transforms. The consensus in >>> the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If >>> you have concerns about this decision please respond on the TLS list >>> by April 11, 2014. >>> >>> Thanks, >>> >>> Joe >>> [Speaking for the TLS chairs] >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > From SRS0=RURu=2D=acm.org=bmoeller@srs.kundenserver.de Mon May 5 12:54:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8861A0491 for ; Mon, 5 May 2014 12:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK7JPYSPOHOi for ; Mon, 5 May 2014 12:54:45 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2551A047B for ; Mon, 5 May 2014 12:54:44 -0700 (PDT) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LkhPw-1XFMHD2To4-00aR82; Mon, 05 May 2014 21:54:39 +0200 Received: by mail-yh0-f54.google.com with SMTP id i57so1070937yha.13 for ; Mon, 05 May 2014 12:54:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.141.113 with SMTP id f77mr50930541yhj.128.1399319678665; Mon, 05 May 2014 12:54:38 -0700 (PDT) Received: by 10.170.65.3 with HTTP; Mon, 5 May 2014 12:54:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 21:54:38 +0200 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=20cf303dd2285fc9d904f8ac80f8 X-Provags-ID: V02:K0:uuedErNmEl2n4Btj7lPfobr9KG501GzM+leOPBfpPvN W6Cj2ceTgb+/iFwdS48ZHRQRpUTO4rlLGNqaEpias/KO1nCU70 iFG7dvvOCvfNgA/FUSqdWY5hfOzPYdzJdhYpKClC2wrB9gSp/t LxQZGTZZ8edQqTRKwA1ZZI72fvfKDnGOtGeYKdGtAzWQ63l/G3 W4OPNFCHRjcPUR0h++uNP7zv0xdpsqownWCnY16oFqK4RVULb+ n4+H8WUAr6SWJPgowO8J5XLUJVdKHk7MeT/idFEWYnzuH0dLB9 Fb+tL+bUkT2lcQmzJGA/7yOpcHa0faaE+qMLtLhQjP02rjYyus WDmPp8vcmVt8dSYKZKarQej0Dc4C9pVFamvY/gT5cfTqY97Guv EPZ+vrb3VkDDJHmMj7q2FFAbBJahsj+e1FvjxNSX430OQ2mKQH w4Zke Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3hGOlx9mQa8JusnM6BNvKtlECJQ Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:56:31 -0000 --20cf303dd2285fc9d904f8ac80f8 Content-Type: text/plain; charset=UTF-8 Nico Williams : > > > On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller wrote > > >> [...] I think we'll need a requirement for clients and servers > >> implementing this spec to do one of the following, because an attacker > can't > >> be expected to opt in to extended master secrets in its handshakes: > >> > >> (1) If the current session does not use an extended master secret, don't > >> allow renegotiation. > >> > >> (2) If a session does not use an extended master secret, don't allow it > to > >> be resumed. > > Why not both? > As I wrote earlier, (2) is cleaner but would entirely prevent session resumption between updated implementations and legacy implementations, and thus doesn't seem viable to roll out immediately. Losing session resumption for most connections can be significant for computational cost and latency. Bodo --20cf303dd2285fc9d904f8ac80f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:
> On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller <bmoeller@acm.org> wrote
= =C2=A0
>> [...]=C2=A0I think we'll need a requirement for clients and se= rvers
>> implementing this spec to do one of the following, because an atta= cker can't
>> be expected to opt in to extended master secrets in its handshakes= :
>>
>> (1) If the current session does not use an extended master secret,= don't
>> allow renegotiation.
>>
>> (2) If a session does not use an extended master secret, don't= allow it to
>> be resumed.

Why not both?

As I wrote earlier,= =C2=A0(2) is cl= eaner but would entirely prevent session resumption between updated impleme= ntations and legacy implementations, and thus doesn't seem viable to ro= ll out immediately. =C2=A0Losing session resumption for most connections ca= n be significant for computational cost and latency.

Bodo

--20cf303dd2285fc9d904f8ac80f8-- From nobody Mon May 5 13:01:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F110F1A0195 for ; Mon, 5 May 2014 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hf9llYQAuIm for ; Mon, 5 May 2014 13:01:56 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 557A41A0193 for ; Mon, 5 May 2014 13:01:56 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 0467126406A for ; Mon, 5 May 2014 13:01:53 -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=SYWlqeNLZnFaWvMlGBX3 Gorm/TI=; b=yvBOPaU50EbYB+aBvTWD6l4rJ616KpMcrqueMqv0zG/LXoGK/FHU K48s/oMw+wohTwiNWj20O74/tpQcorN9cIJuVyC235A4c4vjeNkU8AUCh5k57LoB WcGE6zNfvbfBfG7NCLBNZ9ule4e3vpKwfTEXI6M3aKj1i64ONzNF0CI= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id AA36E264059 for ; Mon, 5 May 2014 13:01:52 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so3437903wiw.8 for ; Mon, 05 May 2014 13:01:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.221.8 with SMTP id qa8mr17401801wic.39.1399320111604; Mon, 05 May 2014 13:01:51 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 13:01:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 15:01:51 -0500 Message-ID: From: Nico Williams To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lAFMh1KjoL49obDEW9JnOvsNw8M Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:01:57 -0000 On Mon, May 5, 2014 at 2:54 PM, Bodo Moeller wrote: > Nico Williams : >> > On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller wrote > > >> >> >> [...] I think we'll need a requirement for clients and servers >> >> implementing this spec to do one of the following, because an attacker >> >> can't >> >> be expected to opt in to extended master secrets in its handshakes: >> >> >> >> (1) If the current session does not use an extended master secret, >> >> don't >> >> allow renegotiation. >> >> >> >> (2) If a session does not use an extended master secret, don't allow it >> >> to >> >> be resumed. >> >> Why not both? > > > As I wrote earlier, (2) is cleaner but would entirely prevent session > resumption between updated implementations and legacy implementations, and > thus doesn't seem viable to roll out immediately. Losing session resumption > for most connections can be significant for computational cost and latency. (1) alone breaks tls-unique CB, so it's not acceptable unless there's an API for extracting CB and that API makes tls-unique not available. That might seem like a nit to some, but given the state of play in TLS implementations' APIs I think any protocol fix (as opposed to new features) that has API impact should be considered more carefully. (Sure, it's not the end of the world.) (2) is definitely cleaner and I don't see the interop problem: if an old client connects to a new server then the server should not offer resumption, while a new client connecting to an old server should not use session resumption even if offered by the server. (2) only results in reduced performance in old/new or new/old cases, but those should disappear soon enough. Nico -- From nobody Mon May 5 13:20:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A071A0424 for ; Mon, 5 May 2014 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-I8Bi2B5Oxi for ; Mon, 5 May 2014 13:20:39 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE58F1A041F for ; Mon, 5 May 2014 13:20:38 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so6958535wgh.26 for ; Mon, 05 May 2014 13:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6vMOQx88RYWe40xkpNIJDIYb45JM998WUTdfhHPMtnU=; b=sdOPt5RF693WV983aC9oRf5PCNyTsc04hkAp70OhCRngrD5B32pOflofRA9WfCo7Ie GD2hzwKuJ2wHAvWUU8CCe6caBH61pfgoO/yt3mLE6JcEaTT11g9ZgQhPdetLLnBibpD6 dnOQfZhFqTu0fCsQmhg7B4uWiAauacXVbmLLqQAqwJK7qWD/gJuVzD2YSl2tOjXLOeto VpWuN1bsev1KCix1sNtk5psZvALsQcDWNdnVUs6980oXKGYK6yYGOE1lQ+0jP0FioVD2 YKkHX51X0d8QkFPfBLCkNaWVANF4u6DissOvZfvEzWCuxfKSnwS6OemQMPCkDoG84Oh/ Oj4w== MIME-Version: 1.0 X-Received: by 10.180.84.226 with SMTP id c2mr17573369wiz.50.1399321234734; Mon, 05 May 2014 13:20:34 -0700 (PDT) Received: by 10.227.77.10 with HTTP; Mon, 5 May 2014 13:20:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 13:20:34 -0700 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HUtmk5erYgI4mfT1Bp6rzGBOtGM Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:20:40 -0000 On 5 May 2014 12:54, Bodo Moeller wrote: > Losing session resumption for most connections can be significant for > computational cost and latency. At least those are the only costs. At least the session can still be established. There are some use cases that depend on renegotiation that cannot be addressed otherwise. For instance, protecting client certificates from passive inspection. Neither option is good, but perhaps we can allow implementations (or deployments) to pick what measure suits them (or both). I'd certainly put 2 down as the default. From nobody Mon May 5 13:37:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C71A050E for ; Mon, 5 May 2014 13:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA7DO-33sTFR for ; Mon, 5 May 2014 13:37:21 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3A1A01C1 for ; Mon, 5 May 2014 13:37:21 -0700 (PDT) Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MIw2b-1WjLZl1pgP-002Uj0; Mon, 05 May 2014 22:37:16 +0200 Received: by mail-yh0-f51.google.com with SMTP id f10so2815434yha.10 for ; Mon, 05 May 2014 13:37:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.145.9 with SMTP id o9mr28166125yhj.129.1399322235443; Mon, 05 May 2014 13:37:15 -0700 (PDT) Received: by 10.170.65.3 with HTTP; Mon, 5 May 2014 13:37:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 22:37:15 +0200 Message-ID: From: Bodo Moeller To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf303f6ae8c5202804f8ad1842 X-Provags-ID: V02:K0:72YuCwItLtBR+NS9xaKUMSUbhw/5irLK+51Bk1Go7mT 58GFtqFSTGcmwu/TQZ0LNEg5lvm915fH2xurNwGSJXAWVhlNAs lOzXY+a6OF/zk5hxeCdii9x/T9tJ+7SGOq0PSiaC2wFBvIAbzp hAHdGftxjYKSv9zdWHUaSYzQiZcVrO8JuowuuTzJJZBR+JTNpn VVRjpvduCVorBk0uzEcoMUIL28AXrSKUiwqTzg/0JejIethLYe SLglhwZaXURBSOjbijNfZYWd8MsudB5/u8f5sf4m98Dgm5UczL ivgggDwsO8wC7xWqhnr8xUK7vK1J2E/HJfTmNkJWuq+vI4Is46 Swhris3Qp2sFYihBOQ/+uCwn2SQD+iZMpolZIxl0H+qVicsy5k ZavPwtlaIKwFNGIuC6PyNRD8iMol1fHfXgicA2GdlUq3zeombu IBo8p Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F7VYmKVCSQzfFNfJ4ONUmx2_xJc Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:37:22 -0000 --20cf303f6ae8c5202804f8ad1842 Content-Type: text/plain; charset=UTF-8 Martin Thomson : > On 5 May 2014 12:54, Bodo Moeller wrote: > > Losing session resumption for most connections can be significant for > > computational cost and latency. > > At least those are the only costs. At least the session can still be > established. There are some use cases that depend on renegotiation > that cannot be addressed otherwise. For instance, protecting client > certificates from passive inspection. > Yes, that's why I also wrote, "Maybe for servers you'd initially want to pick either approach 1 or approach 2 depending on the particular needs (whether renegotiation is needed at all), while clients initially could allow *both* renegotiation and resumption for new sessions, where whichever comes first for a given session would disallow the other." Neither option is good, but perhaps we can allow implementations (or > deployments) to pick what measure suits them (or both). I'd certainly > put 2 down as the default. > Things definitely should converge towards (2). Bodo --20cf303f6ae8c5202804f8ad1842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:
On 5 May 2014 12:54, Bodo Moeller <bmoeller@acm.org> wrote:
> Losing session resumption for most connections can be significant for<= br> > computational cost and latency.

At least those are the only costs. =C2=A0At least the session can sti= ll be
established. =C2=A0There are some use cases that depend on renegotiation that cannot be addressed otherwise. =C2=A0For instance, protecting client certificates from passive inspection.

Y= es, that's why I also wrote, "Maybe for servers you'd initially want to pick = either approach 1 or approach 2 depending on the particular needs (whether = renegotiation is needed at all), while clients initially could allow *both*= renegotiation and resumption for new sessions, where whichever comes first= for a given session would disallow the other."


Neither option is good, but perhaps we can allow implementations (or
deployments) to pick what measure suits them (or both). =C2=A0I'd certa= inly
put 2 down as the default.

Things definitely s= hould converge towards (2).

Bodo

--20cf303f6ae8c5202804f8ad1842-- From nobody Mon May 5 13:44:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9895A1A0564 for ; Mon, 5 May 2014 13:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MJHK6yyf-55 for ; Mon, 5 May 2014 13:44:38 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62D1A055D for ; Mon, 5 May 2014 13:44:38 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0M4rAD-1X40o01Gdp-00yy4z; Mon, 05 May 2014 22:44:33 +0200 Received: by mail-yk0-f170.google.com with SMTP id 10so1654247ykt.1 for ; Mon, 05 May 2014 13:44:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.164.198 with SMTP id c46mr51476220yhl.103.1399322672312; Mon, 05 May 2014 13:44:32 -0700 (PDT) Received: by 10.170.65.3 with HTTP; Mon, 5 May 2014 13:44:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 22:44:32 +0200 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=20cf303f642ccf372204f8ad326c X-Provags-ID: V02:K0:JA6h1Ln2mx6aXdW4Id1V7MCIWkneWz+3Z0B5ZMYIhHH qkX3OxtMquro9vtKvFXS2+geAlZsnvK15ADJyh+Y/pHt+FVoSj /ahvb56kTHcyiY6fg0fb6TDbZtlkIWgs3VPtC4ZOZ4ZyIn/2FF 7PsDv162lwn0TUzgS2Y6z88oIKctrF4F8YKlvR4Os2Bq2jDfaN TETUVQZU+O9qdHqci4xPwqrDFT7rfT+XRNfrbW3cFstje+MxsW BpC9sIudHKWj01P3K1Ws/BV+yfV2bUkvG5ei8yEk9djg/XImK+ 1aAPPA7lSyTb3B+KpDBr1b3L2d3rkEI7ljJCcK9XAU5Fvqsgry +03WHOq4kmJjKiSVHut1TcXyzv/cn1YC8WM6qxm4RHysKe3KnS GXCvgcSFUyyRzyx2VIn4bDbBfSFQHp9wvSrlDSOazC818OhWR7 gIgah Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o30XcNA2j_v3J9h5SjCPslDLAYM Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:44:39 -0000 --20cf303f642ccf372204f8ad326c Content-Type: text/plain; charset=UTF-8 Nico Williams : (2) only results in reduced performance in old/new or new/old cases, > but those should disappear soon enough. The point is, if you're the first to switch from "old" to "new", this would affect *all* your connections. (Indeed there's no interoperability problem per se, but the performance hit can be nontrivial.) Having (1) available as an intermediate state would make it easier to switch early. Bodo --20cf303f642ccf372204f8ad326c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:

(2) only results in reduced performance in old/new or new/old cases,
but those should disappear soon enough.

The= point is, if you're the first to switch from "old" to "= new", this would affect *all* your connections. =C2=A0(Indeed there= 9;s no interoperability problem per se, but the performance hit can be nont= rivial.) =C2=A0Having (1) available as an intermediate state would make it = easier to switch early.

Bodo

--20cf303f642ccf372204f8ad326c-- From nobody Mon May 5 13:59:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABA1A0656 for ; Mon, 5 May 2014 13:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVrxGWi4O1wT for ; Mon, 5 May 2014 13:59:56 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0C491A065B for ; Mon, 5 May 2014 13:59:56 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 70781318065 for ; Mon, 5 May 2014 13:59:53 -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=788epiE1OMQ2xk4bScyz 8FV4J2k=; b=hhO0siJEW4YWzHIazUtDVpWrYsOH8hCCLFHncChwinmBZKbdSMq+ InKKNrjEAEg9NInP90XDLnyFQX2HgMppEBugOUkTqqell93qjoE8zZiWUe2q5R2r CFRi8RywjE2xCNj2lyMwXAfG2GJhVGReYqm306Ry4v2IYsHrVmw3epQ= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 23E89318064 for ; Mon, 5 May 2014 13:59:52 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so7003579wgh.26 for ; Mon, 05 May 2014 13:59:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.143.109 with SMTP id sd13mr165353wjb.95.1399323591834; Mon, 05 May 2014 13:59:51 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 13:59:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 15:59:51 -0500 Message-ID: From: Nico Williams To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AXcvBcG9VcJIhAVuVlG8TbBIz2o Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:59:57 -0000 On Mon, May 5, 2014 at 3:44 PM, Bodo Moeller wrote: > Nico Williams : > >> (2) only results in reduced performance in old/new or new/old cases, >> but those should disappear soon enough. > > > The point is, if you're the first to switch from "old" to "new", this would > affect *all* your connections. (Indeed there's no interoperability problem > per se, but the performance hit can be nontrivial.) Having (1) available as > an intermediate state would make it easier to switch early. Several optimizations are possible. Here's a possible set of rules: - neither new clients nor new servers should permit renegotiation within resumed connections when talking to an old peer - new clients should not permit resumption of renegotiated connections to old servers unless the inner connection is bound to the outer and - tls-unique will not be extracted or will be made unavailable when talking to old servers - new servers should not offer nor permit resumption by old clients when tls-unique CB may be extracted OR they should disallow tls-unique CB extraction Is that complete? I think so. But that's fairly complicated and mistakes could be made in interpreting it. We all need resumption fixed, and we're getting pretty good at deploying new TLS implementations (because goto fail bug, because heartbleed). I'd rather simplify things by going with (2) alone. Nico -- From nobody Mon May 5 14:13:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDEA1A0198 for ; Mon, 5 May 2014 14:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8Wl7cvRk7Km for ; Mon, 5 May 2014 14:13:52 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by ietfa.amsl.com (Postfix) with ESMTP id 978171A011A for ; Mon, 5 May 2014 14:13:51 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0LejD4-1XCZAj0TU6-00qUzF; Mon, 05 May 2014 23:13:47 +0200 Received: by mail-yk0-f180.google.com with SMTP id q9so6688515ykb.39 for ; Mon, 05 May 2014 14:13:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.148.244 with SMTP id v80mr1105900yhj.19.1399324426189; Mon, 05 May 2014 14:13:46 -0700 (PDT) Received: by 10.170.65.3 with HTTP; Mon, 5 May 2014 14:13:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 23:13:46 +0200 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=20cf303a2edf5942be04f8ad9b16 X-Provags-ID: V02:K0:37xKjOgCPohn3sjb96lCxiYIuwe2cu5RKRfwwX6+6g/ x2kWCoz/zzCA0Ptol56RIxNtMWMdVkeTJ2BA3wj6/MvP5iQMQc 7MyAm/zPjvwUmyXo0OcPyZm7WTWjZEdTrSvN965gAfL09D+fhD UcLs5omjyjuHpmiX0r/MYe3FKhEl8V/S+7z9XgraO9woZIOD87 NYxT8IW1OwDLaJ7AcBgCSTRC44VwRVZBplMfv840F3B4Sa9le+ gpQcUX0sR4TlfzIEMqKi4Jj+z62q7TMlswEFjQ2gBkovJ74+GT ZlMOBCVqhVNEqKgsqEm5tY39mpgb484EYBZR4W4FpE/19hfG0n D3Jy1PlVERQpsNChvHYbO43YEXntt/aHNgozPocjOhBkiLpRHW bjOnWHJw7g9ngnNBxqXfSG/xIK51A2XXuWugTF/rTHZz1wg6qe pbWTz Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JxiO0Ev46RUrx6-oClHXHMptNWA Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:13:52 -0000 --20cf303a2edf5942be04f8ad9b16 Content-Type: text/plain; charset=UTF-8 > > > We all need resumption fixed, and we're getting pretty good at > deploying new TLS implementations (because goto fail bug, because > heartbleed). Well, these examples have fixes that you can just roll out fully on whatever system you control without causing any disruption by doing so, other than potentially to attackers: with these, there's no penalty for moving first. (2), unfortunately, isn't that easy. --20cf303a2edf5942be04f8ad9b16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We all need resumption fixed, and we're getting pretty good at
deploying new TLS implementations (because goto fail bug, because
heartbleed).

Well, these examples have fixe= s that you can just roll out fully on whatever system you control without c= ausing any disruption by doing so, other than potentially to attackers: wit= h these, there's no penalty for moving first. =C2=A0(2), unfortunately,= isn't that easy.

--20cf303a2edf5942be04f8ad9b16-- From nobody Mon May 5 14:59:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4A1A03C2 for ; Mon, 5 May 2014 14:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xQLzUT801-a for ; Mon, 5 May 2014 14:59:14 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id BBE341A037A for ; Mon, 5 May 2014 14:59:14 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id f73so2001282yha.28 for ; Mon, 05 May 2014 14:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BbRMS2UTwkxr7UxNLGOdCqp20zKbXfmWsLtFu0kp0Q4=; b=kCC8u3rSpDlKSVO93hvMwS1AG5qrt1bQhcZrsUIwKHavPorIF99AKt147Oym+5YBV4 Bi5RZbBaRlKrp7TY8HcVIEGbC9Mf0VwZEKS/3A6gLvt9BnVuq0d6eXYLvxnx0EaJQVue JH/J4zi1+sRVYX1xwoXz2mKlajadZ0szd4AUJIm+vWchZL2SA4hvsET7kohFienJZcRv 8gdQEXkyggUjFocudMDbOHLeonHwoASAyzmSCWW0yuad7EBekSmVBpi/KhtXVSaBWtGF bD51+0fRftNFqMYOyDQL9DTuUt9TAhAylE792mABQnQ12Nag10P18NojYL5Lbd/CflUj kydA== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr52546943yhh.66.1399327151145; Mon, 05 May 2014 14:59:11 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 5 May 2014 14:59:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 14:59:11 -0700 Message-ID: From: Watson Ladd To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gjnVxsP8poFJQBzxelWqW8UEbKM Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:59:16 -0000 On Mon, May 5, 2014 at 2:13 PM, Bodo Moeller wrote: >> >> We all need resumption fixed, and we're getting pretty good at >> deploying new TLS implementations (because goto fail bug, because >> heartbleed). > > > Well, these examples have fixes that you can just roll out fully on whatever > system you control without causing any disruption by doing so, other than > potentially to attackers: with these, there's no penalty for moving first. > (2), unfortunately, isn't that easy. I vote for (1). Hardly anyone uses renegotation. Resumption is commonly used on the web today. Let's hurt the uncommon usecase instead of having a widespread performance regression. Sincerely, Watson Ladd > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon May 5 16:03:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331EB1A044C for ; Mon, 5 May 2014 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBV4E-D_K8lL for ; Mon, 5 May 2014 16:03:24 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D13411A047D for ; Mon, 5 May 2014 16:03:21 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 771582007F21C for ; Mon, 5 May 2014 16:03:18 -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=8TbJUSc5DBLSnvC6urTy FpwwUQQ=; b=Ig1ZigNs1caM3ez2fINvGCh9XfQuQzJDoaJxsyv3GGNxTx62bRTR Q9GXBmP2zV7YeNc1Ja1daD6mNzxuD4LbYpA3BlPy0yjuwGs5IH8QYreZdvztMzbM ZbRFeqQ/2gQ1wbqIawtpB2XByFcIEdRhk6pq/Apw3Xw1RzymlLbKPmg= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 2C5CD2007F21D for ; Mon, 5 May 2014 16:03:17 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so6366473wib.12 for ; Mon, 05 May 2014 16:03:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr17875016wic.5.1399330996640; Mon, 05 May 2014 16:03:16 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 16:03:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 18:03:16 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tw2MvJM6ME681j4nGhlPF9BB628 Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 23:03:25 -0000 On Mon, May 5, 2014 at 4:59 PM, Watson Ladd wrote: > On Mon, May 5, 2014 at 2:13 PM, Bodo Moeller wrote: >>> >>> We all need resumption fixed, and we're getting pretty good at >>> deploying new TLS implementations (because goto fail bug, because >>> heartbleed). >> >> >> Well, these examples have fixes that you can just roll out fully on whatever >> system you control without causing any disruption by doing so, other than >> potentially to attackers: with these, there's no penalty for moving first. >> (2), unfortunately, isn't that easy. > > I vote for (1). Hardly anyone uses renegotation. Resumption is > commonly used on the web today. Let's hurt the uncommon usecase > instead of having a widespread performance regression. Even if we have consensus to remove renego in 1.3, for everyone else there's a difference between "oops, it fails" and "hmm, it's not as fast as usual". This isn't hurting the uncommon use-case, but breaking a rare but not that rare usage. Nico -- From nobody Mon May 5 22:32:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591CC1A072F for ; Mon, 5 May 2014 22:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E_r2XoiAMjX for ; Mon, 5 May 2014 22:32:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C70081A072D for ; Mon, 5 May 2014 22:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3914; q=dns/txt; s=iport; t=1399354334; x=1400563934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rPURbpC9A7wnXDkNUwms2sO80uMdWv7Y8zhgHe6S/HQ=; b=buICLzxPedTLg3rgRRxEAkMDWIal5wX2EcDeaEBZW6d1iqKhG0oWhMyu u4MAjFQ6ghmQyuM2jwAQXJXN5LkXUyMAHzbMApYsn/bgIfgPxH1o9svzw ka8VcplYm35Jh4mYTyLnsE6033UoXJO5cSECLMdeDLY/CaWW07xxRCkRz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAC9zaFOtJA2B/2dsb2JhbABYgwZPWL0chzuBGRZ0giUBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYg5CA3NaRMEjh8zB4MqgRUEmTeSeIM0gi8 X-IronPort-AV: E=Sophos;i="4.97,994,1389744000"; d="scan'208";a="322642561" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 06 May 2014 05:32:14 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s465WDvK025250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 05:32:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.99]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 6 May 2014 00:32:13 -0500 From: "Joseph Salowey (jsalowey)" To: Michael StJohns Thread-Topic: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: AQHPSSM6qiIeFUDRHUase0LCUT6SLpskiL+AgATejwCACjNNAA== Date: Tue, 6 May 2014 05:32:13 +0000 Message-ID: References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> In-Reply-To: <535FE558.2090306@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <49E333C7AA775644A4DBB218EAE1D15C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/edTTtF32ZNOWhsZ3DCWKCQ9pk0g Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 05:32:20 -0000 On Apr 29, 2014, at 10:46 AM, Michael StJohns wrot= e: > On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote: >> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use reco= rd layer protection of type AEAD. The Editor is requested to make the appro= priate changes to the draft on github. >=20 > Sorry - I'm coming late here. Does this also imply the complete eliminat= ion of the integrity only cipher suites? >=20 [Joe] Its possible to have AEAD modes that provide only authentication, how= ever I don't think that the currently defined AEAD ciphers support authenti= cation only so its possible that some modification may need to be made to s= upport this. =20 > With respect to the AEAD approach and with respect to composited AEAD cip= her suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for ex= ample), does this also imply that the key expansion phase will never be use= d to generate MAC keys, and that the cipher suite has to provide whatever m= echanisms that are required to split the AEAD key into underlying encryptio= n/integrity keys if required? >=20 [Joe] Yes, the cipher suite would be responsible for deriving the appropria= te keys from the key material it is given.=20 > Next (reading from the commited editors copy), this refers to 5116 which = uses a one-size fits all approach that doesn't really fit all sizes, especi= ally for composited AEAD. E.g. the draft describes this generally as an in= crementing value. For AEAD suites that comply with 5116, that should be pa= rt of the suite specification - not TLS. For TLS, this just needs to be an= normatively opaque, per-message field. Instead, place an Informative s= ection which recommends how to do this with AEAD suites that currently exis= t. >=20 [Joe] I think I'm missing your point here. I thought the existing cipher su= ites did define how the nonce is generated and the TLS document just provid= es some guidance on nonce generation. =20 > And finally, as I've noted many times before, deriving IV/nonce material = from the master_secret at the same time as deriving keys is not securely su= pportable in hardware. >=20 [Joe] So currently with AES-GCM and AES-CCM then nonce is partially deriv= ed from the Client and Server IV. If I remember correctly the TLS derivat= ion by splitting up the derived key material into secret keys and IVs is pr= oblematic. Can this part of the problem be solved by changing the way TLS = derives keys and IVs?=20 >>=20 >> Joe >> [For the chairs] >> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) wrote: >>=20 >>> TLS has supported a number of different cipher types for protecting the= record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher a= nd AEAD Cipher. The construction of the CBC mode within TLS has been shown = to be flawed and stream ciphers are not generally applicable to DTLS. Using= a single mechanism for cryptographic transforms would make security analys= is easier. AEAD ciphers can be constructed from stream ciphers and block = ciphers and are defined as protocol independent transforms. The consensus = in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you = have concerns about this decision please respond on the TLS list by April 1= 1, 2014. >>>=20 >>> Thanks, >>>=20 >>> Joe >>> [Speaking for the TLS chairs] >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 6 02:13:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1531A066F for ; Tue, 6 May 2014 02:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22pgwmxrmdzy for ; Tue, 6 May 2014 02:13:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8D1A0188 for ; Tue, 6 May 2014 02:13:26 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s469DLYE009991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 May 2014 05:13:22 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s469DJSM022570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 May 2014 05:13:20 -0400 Message-ID: <1399367598.30930.12.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Tue, 06 May 2014 11:13:18 +0200 In-Reply-To: References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aBqOCtoyOKAesSK4fIzm-XldUNY Cc: tls@ietf.org Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 09:13:27 -0000 On Mon, 2014-05-05 at 10:23 -0700, Eric Rescorla wrote: > You're probably thinking of: > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > This seems like a reasonable kind of thing for the WG to > consider, I believe that this draft addresses the existing concerns with the DH ciphersuites I'm aware of, and would be very good if the TLS WG would adopt it. regards, Nikos From nobody Tue May 6 02:24:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A931A0780 for ; Tue, 6 May 2014 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeiLrf5FKIyX for ; Tue, 6 May 2014 02:24:30 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-06-out.s.azet.sk [91.235.53.31]) by ietfa.amsl.com (Postfix) with ESMTP id A5E751A0299 for ; Tue, 6 May 2014 02:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1399368264; bh=srZiI/5H3BaRGyAhhm50B/wHmAWeAg8+KbAP2zXlTOA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aHskz2rVvZ04+HUOs+hp1rLb+xjbPIcXdEt+tuIeaAfX5KBsup6uKmu3EpXpfZc/V YRpQsnPsIBSlOtb4CRVsKSCBPxH4PJxcDE3XVFdYkhYhJXJAv0mmtLwNUAlWCOgOTY 9hDI+/vDioLkqo/xRanP4BDLGN2/rn3kAUZs6dbQ= X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (tor.pm-ib.de [83.133.106.73]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 8FD667D for ; Tue, 6 May 2014 11:24:18 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 8FD667D Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk Message-ID: <5368AA3A.8010206@azet.sk> Date: Tue, 06 May 2014 11:24:10 +0200 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> <535FD8AE.6050007@pobox.com> <535FE275.6090701@pobox.com> In-Reply-To: <535FE275.6090701@pobox.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zMoQ3S35_DKvfKs7LUAeLsa0L54 Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 09:24:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29.04.2014 19:33, Michael D'Errico wrote: > Martin Thomson wrote: >>> I suggest [not naming a mandatory-to-implement cipher suite in the >>> TLS 1.3 spec.]. There are too many [cipher suites] to choose from >>> and nobody will listen anyway. >> >> That's a recipe for interoperability failure. > > I'm suggesting that the TLS 1.3 spec. is not the place for this piece > of information since it is a moving target: > > TLS 1.0 required TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > TLS 1.1 required TLS_RSA_WITH_3DES_EDE_CBC_SHA. > TLS 1.2 required TLS_RSA_WITH_AES_128_CBC_SHA > > Current consensus says none of those previously-mandatory ciphers will > even be compatible with TLS 1.3. > > A Best Current Practice document like draft-sheffer-tls-bcp-02 that > tracks best practices is more useful than having the TLS spec. become > obsolete soon after it's published. BTW that draft suggests these > cipher suites: > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > Mike > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > There are good reasons why not to use AES-GCM in software implementation of TLS https://www.imperialviolet.org/2012/10/21/nist.html https://www.imperialviolet.org/2013/10/07/chacha20.html Chacha20+Poly1305 is more efficient on CPUs without special instructions to implement AES and GCM. Also secure implementation which doesn't leaks timing information on such CPUs is easier. Fedor -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTaKo6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOt47sQAJN2v9TIpA+1eEcJoK0yIEem cKhPpZaYwKhKnthk4RYnV/hBFn6/Ij59p14Als+e5ZdMLB6uiqwurgEoRi7OKZRK QFKyhrqOrjqX2UrhKbPY6wPJ+WY+Qq8PA8OA0KAp3etSTgcopaCTBEUSUkaMiqiG RJ8MzrzyQQALPP+/gODaBIa0MF8y2jOdqAqn7IUaKM9auYeSwEaRzMfhKFITvrkC a/YZnEB1KkqezKvxocAUw3ttV2kAiFJyGPHPA3GB0nUamw3CUspFIBIuZ9sjv1OW ih90AfsobMdm1lZrZwn1WHdValUKYy3VRg2NEH+AgLfhaMbnOgBlCBR3c1edxhAX Dl6o8VmAI0HAOYKWhLxC9NkpPPbOqXJk8r29R+Ch89fdXHXmRMJ9StK5LKP+gKCx qvVIK3Dp3ITxB5jULX6O1mrI6oGKRpirwlD3ixNujJ+wmc4AmJ3ALiniWOPv6b3T wn/4jikp2IkUnddVyMZOaYSjpflhcnO/WOA0p0nmtprIyD61FQ5w6MMPoEkcXOfz ngMxYS9Pr0+OwbaAhkaJpbXLre3Txc/JcW1Bi/z7o/MCWqApkAW5xhQrKUcDRzNb ToJ5CX9beSvQHr90H7o/JbNsivJEim9vLLWO7yOiC1Gv/LYHhoElc7fk4o/t1kWG WFxsQZshTrSIZArecUVb =avO6 -----END PGP SIGNATURE----- From SRS0=LkZq=2E=acm.org=bmoeller@srs.kundenserver.de Tue May 6 02:49:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8991A028C for ; Tue, 6 May 2014 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqee0Q4paCDE for ; Tue, 6 May 2014 02:49:15 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1F1A0173 for ; Tue, 6 May 2014 02:49:15 -0700 (PDT) Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0M9L3K-1WYF910YVa-00CfJZ; Tue, 06 May 2014 11:49:09 +0200 Received: by mail-yh0-f46.google.com with SMTP id 29so411010yhl.33 for ; Tue, 06 May 2014 02:49:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.164.198 with SMTP id c46mr56532484yhl.103.1399369748143; Tue, 06 May 2014 02:49:08 -0700 (PDT) Received: by 10.170.65.3 with HTTP; Tue, 6 May 2014 02:49:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 May 2014 11:49:08 +0200 Message-ID: From: Bodo Moeller To: Nico Williams Content-Type: multipart/alternative; boundary=20cf303f642cbf659004f8b8283b X-Provags-ID: V02:K0:ozcrFDUOmEkE0DaLzXqXJ50tnMg7AI357OjiSXAorRT sRV4tv57rM7DPG0GEM4xptvcELYrl3/DywUSb+HBWmWuTIY/gW aurdO0UYPOZnzCrPcBFbzfN13zrmCUoNVVYAEz0arMl3xVY+V2 2+f88ki63pKLqCzSKHB8tbK/UY0sYI6UmTrar8Ym5ksibnFpgM mnXnAP6MaT9LAkPQDEJAWX0piwfDruxtOGbXqgtkMT/XyJYehY lB4zRYrvORz0xouiPI+pnlWX061JQxUkHwOSOSe1NZ7HbP/wCU F5DXZrLQ7EKN0WmmEnqjgM6cFzuojvy6plLHxsdQMy4e1yJpI8 hxirK+MamQzdVbxT6SZhR/sCEXpI9sd0ij3k+LTmUyvtDn6rCt anZ0BMy98elFSh/3KPLYKmoeB1WciTLDXY5dIIu9dnpj4AP2lV kuDMR Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pNBDDosXWu_eOcQ1R_WGpT5lDDs Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:01:01 -0000 --20cf303f642cbf659004f8b8283b Content-Type: text/plain; charset=UTF-8 Nico Williams : > On Mon, May 5, 2014 at 4:59 PM, Watson Ladd wrote: > > > I vote for (1). Hardly anyone uses renegotation. Resumption is > > commonly used on the web today. Let's hurt the uncommon usecase > > instead of having a widespread performance regression. > > Even if we have consensus to remove renego in 1.3, for everyone else > there's a difference between "oops, it fails" and "hmm, it's not as > fast as usual". This isn't hurting the uncommon use-case, but > breaking a rare but not that rare usage. I don't want to break renegotiation entirely, hence my suggestion to allow servers to pick either (1) [disallow renegotiation with legacy clients] or (2) [disallow session resumption for legacy clients] at first. My concern regarding (2) is that "It's not as fast as usual" may actually manifest as "My servers are suddenly overloaded and I'll have to revert the software update". (1) is meant for early adopters, so that they won't have to regret being early adopters. Past a certain stage of adoption, everyone should just go to (2) directly. Bodo --20cf303f642cbf659004f8b8283b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:
On Mon, May 5, 2014 at 4:59 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
=C2=A0
> I vote for (1). Hardly anyone uses renegotation. Resumption is
> commonly used on the web today. Let's hurt the uncommon usecase > instead of having a widespread performance regression.

Even if we have consensus to remove renego in 1.3, for everyone else<= br> there's a difference between "oops, it fails" and "hmm, = it's not as
fast as usual". =C2=A0This isn't hurting the uncommon use-case, bu= t
breaking a rare but not that rare usage.

I = don't want to break renegotiation entirely, hence my suggestion to allo= w servers to pick either (1) [disallow renegotiation with legacy clients] o= r (2) [disallow session resumption for legacy clients] at first.

My concern regarding (2) is that "It's not as = fast as usual" may actually manifest as "My servers are suddenly = overloaded and I'll have to revert the software update". =C2=A0(1)= is meant for early adopters, so that they won't have to regret being e= arly adopters. =C2=A0Past a certain stage of adoption, everyone should just= go to (2) directly.

Bodo

--20cf303f642cbf659004f8b8283b-- From nobody Tue May 6 05:52:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE121A02FE for ; Tue, 6 May 2014 05:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeEhlimAiY-G for ; Tue, 6 May 2014 05:52:09 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2541A02F0 for ; Tue, 6 May 2014 05:52:09 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hl10so6195426igb.17 for ; Tue, 06 May 2014 05:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/9of7c8MnhYWNVqXKPCuXF3n1ZfLlnrQQzWS+3tKxzk=; b=Az7xVEuArk0Iwx6LaC8IXKl3Vu0ZdEQ4J49jdMFgQFqiha+HknHwT/ksm2CyA/nD2P v4Gm+MPhKHdWHhMvZMYc/bRURD0q19qDDuHJI9X41+MN7VOVjZ69pwp81CkepTqrlwgt NP8NoklRij50dafQwDNag8Qyt226kDNsvTIc+AHTfmEq2ByqRNNDI1i3A7ZtB60iXChl C/bv2aM4m9e42CFpKvYA0cRA9VkTZ7UCSiJ/y7rjfh14EjyUGQIabZaJxZHa/pU+wM29 hcyClW3EhbvisdeebvJCjDtLgQGHTfe215IflNU0NOz8qNFGBgtxBf646Ev/jnR0WKWS 2O2g== X-Received: by 10.50.153.49 with SMTP id vd17mr32373700igb.40.1399380725222; Tue, 06 May 2014 05:52:05 -0700 (PDT) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id vc5sm38595692igb.3.2014.05.06.05.52.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 05:52:04 -0700 (PDT) Message-ID: <5368DAED.3020000@gmail.com> Date: Tue, 06 May 2014 08:51:57 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , Michael StJohns References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iSd4Sx--qVXr8oi_AiIQxe3ClMM Cc: "tls@ietf.org" Subject: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:52:11 -0000 Hi Joe: In general, an AEAD mode takes as input two strings a and m and a key k, and authenticates a and m, while encrypting m. If m is the empty string, this results in an authentication-only mode. Thus, AEAD modes can be used to provide suitable combinations of authentication and/or encryption. Examples hereof include the GCM mode and CCM mode. Best regards, Rene On 5/6/2014 1:32 AM, Joseph Salowey (jsalowey) wrote: > On Apr 29, 2014, at 10:46 AM, Michael StJohns wrote: > >> On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote: >>> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github. >> Sorry - I'm coming late here. Does this also imply the complete elimination of the integrity only cipher suites? >> > [Joe] Its possible to have AEAD modes that provide only authentication, however I don't think that the currently defined AEAD ciphers support authentication only so its possible that some modification may need to be made to support this. > >> With respect to the AEAD approach and with respect to composited AEAD cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for example), does this also imply that the key expansion phase will never be used to generate MAC keys, and that the cipher suite has to provide whatever mechanisms that are required to split the AEAD key into underlying encryption/integrity keys if required? >> > [Joe] Yes, the cipher suite would be responsible for deriving the appropriate keys from the key material it is given. > > >> Next (reading from the commited editors copy), this refers to 5116 which uses a one-size fits all approach that doesn't really fit all sizes, especially for composited AEAD. E.g. the draft describes this generally as an incrementing value. For AEAD suites that comply with 5116, that should be part of the suite specification - not TLS. For TLS, this just needs to be an normatively opaque, per-message field. Instead, place an Informative section which recommends how to do this with AEAD suites that currently exist. >> > [Joe] I think I'm missing your point here. I thought the existing cipher suites did define how the nonce is generated and the TLS document just provides some guidance on nonce generation. > > >> And finally, as I've noted many times before, deriving IV/nonce material from the master_secret at the same time as deriving keys is not securely supportable in hardware. >> > [Joe] So currently with AES-GCM and AES-CCM then nonce is partially derived from the Client and Server IV. If I remember correctly the TLS derivation by splitting up the derived key material into secret keys and IVs is problematic. Can this part of the problem be solved by changing the way TLS derives keys and IVs? > >>> Joe >>> [For the chairs] >>> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) wrote: >>> >>>> TLS has supported a number of different cipher types for protecting the record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher and AEAD Cipher. The construction of the CBC mode within TLS has been shown to be flawed and stream ciphers are not generally applicable to DTLS. Using a single mechanism for cryptographic transforms would make security analysis easier. AEAD ciphers can be constructed from stream ciphers and block ciphers and are defined as protocol independent transforms. The consensus in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014. >>>> >>>> Thanks, >>>> >>>> Joe >>>> [Speaking for the TLS chairs] >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue May 6 08:11:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261D81A035A for ; Tue, 6 May 2014 08:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZUHdMzIuxea for ; Tue, 6 May 2014 08:11:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 508D71A048C for ; Tue, 6 May 2014 08:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5037; q=dns/txt; s=iport; t=1399389061; x=1400598661; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yOfL0d06Sun9P0S68g56lmenfbHBTFfNc9lbaYE8dS4=; b=IK/nmSCMhgNKgsBzDqWEBtCcT8bH1mwhCwYwR8fKRJwWBOFZUrRQUetb OXhMGRGlVHdo74l/VCzn6J9B8crwuxAgka7mooYt7FzJuW3c3tFIAIu4r Iw7m+KuD7DZP6emmYqRJ265I+/yZKkPRnHox7QWqQ5nU3hNoKGL4/dNYr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACP7aFOtJA2B/2dsb2JhbABWA4MGT1i9I4c5gR8WdIIlAQEBAwEBAQFrCwULAgEIDgouIQYLJQIEDgWILQMJCA3HMQ2GRBMEjDuBNREBHSMQBxGDGYEVBIlOglWLIoFyjRqFYYF1gT+Bdjk X-IronPort-AV: E=Sophos;i="4.97,997,1389744000"; d="scan'208";a="322555731" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 06 May 2014 15:11:01 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s46FB1gR030551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 15:11:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.99]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 6 May 2014 10:11:00 -0500 From: "Joseph Salowey (jsalowey)" To: Rene Struik Thread-Topic: (offline note) Re: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: AQHPSSM6qiIeFUDRHUase0LCUT6SLpskiL+AgATejwCACjNNAIAAet2AgAAm2gA= Date: Tue, 6 May 2014 15:11:00 +0000 Message-ID: <5528AE3F-2483-42EA-949F-E3FC6774A4FC@cisco.com> References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> <5368DAED.3020000@gmail.com> In-Reply-To: <5368DAED.3020000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.96] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3C0D5DCAE8BE2940AEDE29D479FB5681@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YYCS_RqQRVj6zJAXBo-BrJik-_8 Cc: "tls@ietf.org" Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 15:11:07 -0000 On May 6, 2014, at 5:51 AM, Rene Struik wrote: > Hi Joe: >=20 > In general, an AEAD mode takes as input two strings a and m and a key k, = and authenticates a and m, while encrypting m. If m is the empty string, th= is results in an authentication-only mode. >=20 > Thus, AEAD modes can be used to provide suitable combinations of authenti= cation and/or encryption. Examples hereof include the GCM mode and CCM mode= . >=20 [Joe] Yes, but I don't think any of the defined cipher suites for AES-GCM o= r AES-CCM support an authentication-only mode. If authentication-only supp= ort is desired then additional cipher suites would have to be defined. =20 > Best regards, Rene >=20 > On 5/6/2014 1:32 AM, Joseph Salowey (jsalowey) wrote: >> On Apr 29, 2014, at 10:46 AM, Michael StJohns w= rote: >>=20 >>> On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote: >>>> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use re= cord layer protection of type AEAD. The Editor is requested to make the app= ropriate changes to the draft on github. >>> Sorry - I'm coming late here. Does this also imply the complete elimin= ation of the integrity only cipher suites? >>>=20 >> [Joe] Its possible to have AEAD modes that provide only authentication, = however I don't think that the currently defined AEAD ciphers support authe= ntication only so its possible that some modification may need to be made t= o support this. >>=20 >>> With respect to the AEAD approach and with respect to composited AEAD c= ipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for = example), does this also imply that the key expansion phase will never be u= sed to generate MAC keys, and that the cipher suite has to provide whatever= mechanisms that are required to split the AEAD key into underlying encrypt= ion/integrity keys if required? >>>=20 >> [Joe] Yes, the cipher suite would be responsible for deriving the approp= riate keys from the key material it is given. >>=20 >>=20 >>> Next (reading from the commited editors copy), this refers to 5116 whic= h uses a one-size fits all approach that doesn't really fit all sizes, espe= cially for composited AEAD. E.g. the draft describes this generally as an = incrementing value. For AEAD suites that comply with 5116, that should be = part of the suite specification - not TLS. For TLS, this just needs to be = an normatively opaque, per-message field. Instead, place an Informative= section which recommends how to do this with AEAD suites that currently ex= ist. >>>=20 >> [Joe] I think I'm missing your point here. I thought the existing cipher= suites did define how the nonce is generated and the TLS document just pro= vides some guidance on nonce generation. >>=20 >>=20 >>> And finally, as I've noted many times before, deriving IV/nonce materia= l from the master_secret at the same time as deriving keys is not securely = supportable in hardware. >>>=20 >> [Joe] So currently with AES-GCM and AES-CCM then nonce is partially de= rived from the Client and Server IV. If I remember correctly the TLS deri= vation by splitting up the derived key material into secret keys and IVs is= problematic. Can this part of the problem be solved by changing the way T= LS derives keys and IVs? >>=20 >>>> Joe >>>> [For the chairs] >>>> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) wrote: >>>>=20 >>>>> TLS has supported a number of different cipher types for protecting t= he record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher= and AEAD Cipher. The construction of the CBC mode within TLS has been show= n to be flawed and stream ciphers are not generally applicable to DTLS. Usi= ng a single mechanism for cryptographic transforms would make security anal= ysis easier. AEAD ciphers can be constructed from stream ciphers and bloc= k ciphers and are defined as protocol independent transforms. The consensu= s in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If yo= u have concerns about this decision please respond on the TLS list by April= 11, 2014. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Joe >>>>> [Speaking for the TLS chairs] >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 From nobody Tue May 6 08:25:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4811A0357 for ; Tue, 6 May 2014 08:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZyu090Dfe-V for ; Tue, 6 May 2014 08:25:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2156A1A00A2 for ; Tue, 6 May 2014 08:25:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0D9C32AAA03; Tue, 6 May 2014 15:25:15 +0000 (UTC) Date: Tue, 6 May 2014 15:25:14 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140506152514.GY27883@mournblade.imrryr.org> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> <1399367598.30930.12.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1399367598.30930.12.camel@dhcp-2-127.brq.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lAzZYgwzjp6RAm7uJ7Qjs844VoM Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 15:25:21 -0000 On Tue, May 06, 2014 at 11:13:18AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, 2014-05-05 at 10:23 -0700, Eric Rescorla wrote: > > You're probably thinking of: > > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > > > This seems like a reasonable kind of thing for the WG to > > consider, > > I believe that this draft addresses the existing concerns with the DH > ciphersuites I'm aware of, and would be very good if the TLS WG would > adopt it. Other collections of DHE groups work in a subgroup of order "q", where log(q) ~ 2^{security factor}. This speeds up the arithmetic. (Squares can be reduced modulo the much smaller q). Is there a reason to avoid those? Problems with constant-time implementation? Other concerns? -- Viktor. From nobody Tue May 6 08:51:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC481A02B8 for ; Tue, 6 May 2014 08:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOfBBpjw_tsy for ; Tue, 6 May 2014 08:51:39 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EC5D81A037E for ; Tue, 6 May 2014 08:51:37 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 79so2205141ykr.31 for ; Tue, 06 May 2014 08:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BL92uEY1Zme8zDxOvvQnbYPOdOhfAInspKajJIbKPj4=; b=mo0HIlvfgNu/qN1TV9uZLSYqSly5EBlW+MxodxAHNKMEBfXONWh1G7znNdRFD92xdx 9zXY1EAjXT0IGqMuKoKuJC/RqOGEqDDzZcMfSzb9qeMaL0KbSSSyo2ljRZrK2NxaXorw 5r1vjdWLuXZU+1w/gdo+5lSDqblybPrb06802hYs9IWOMjSL7HMuzFazTD6D6C1fhIgm iuyVrMNKHq5kjm4/1fSkU2OSUwba1ZhHDWAJuob+WUxDpZBLTXL8dm2iI3DeGWc9JNms dBALxeR2f0niJIi+k0Ce0nmomzsAQNHNv27BQnJvaxeR4t952O5tlZRkBYm93E2vF4jj py6Q== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr58910203yhj.63.1399391494070; Tue, 06 May 2014 08:51:34 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 6 May 2014 08:51:33 -0700 (PDT) In-Reply-To: <20140506152514.GY27883@mournblade.imrryr.org> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> <1399367598.30930.12.camel@dhcp-2-127.brq.redhat.com> <20140506152514.GY27883@mournblade.imrryr.org> Date: Tue, 6 May 2014 08:51:33 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9LZnBq2qMSWglgghOb-QdRjJjB4 Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 15:51:42 -0000 On Tue, May 6, 2014 at 8:25 AM, Viktor Dukhovni wrote: > On Tue, May 06, 2014 at 11:13:18AM +0200, Nikos Mavrogiannopoulos wrote: > >> On Mon, 2014-05-05 at 10:23 -0700, Eric Rescorla wrote: >> > You're probably thinking of: >> > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 >> >> > This seems like a reasonable kind of thing for the WG to >> > consider, >> >> I believe that this draft addresses the existing concerns with the DH >> ciphersuites I'm aware of, and would be very good if the TLS WG would >> adopt it. > > Other collections of DHE groups work in a subgroup of order "q", > where log(q) ~ 2^{security factor}. This speeds up the arithmetic. > (Squares can be reduced modulo the much smaller q). Is there a > reason to avoid those? Problems with constant-time implementation? > Other concerns? How do you know I in fact gave you an element of that subgroup? The obvious fixes are all very slow. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue May 6 09:18:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B821A0148 for ; Tue, 6 May 2014 09:18:21 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FTOpFuLfzRs for ; Tue, 6 May 2014 09:18:15 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0F1A00ED for ; Tue, 6 May 2014 09:18:15 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l6so5059740qcy.31 for ; Tue, 06 May 2014 09:18:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=mJK9fazX8uyZUq4Gh/bPdoRJpU36WmY3GaWoF0FEiNc=; b=HdqjRk+98gplv/QQTGa2IM9om1+tmUtbBTtakpXuTibjsPoAZnlB2zNCXZHX2QcjiZ cJaFWh1qJMrF184TbeTH1LA798+7nle2d9DlfkQSd6EMkoCgUIrD0lQz3b3tdwO7a1Zy s/XN/+ffGl7Ai28W6AtjEXAGKCaZn1/UJAFSoq6ezlz7n8jVMkebge6+WzweucZBaxLW 0M3d4A2DjZpOP8a1furVdliRLoU7p0Iq8Z9Ink+5+J406WjbaTQGEHsE5AHSI7kKFmti cYgDbhyHZsw+bcool5KtaOs3jTLH1FLjg0TyNjSINBs1dN8Is4IwOW0qbb1J7c1UHIQV P1Bw== X-Gm-Message-State: ALoCoQlJBFTMiYZ1Kjo03O4uMIcec//9GoBdTzf1EfqBSePf0T+MTkMi6/3g/XnJRV5jn3lOBays X-Received: by 10.140.87.5 with SMTP id q5mr52439413qgd.43.1399393091412; Tue, 06 May 2014 09:18:11 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id j7sm24289349qab.27.2014.05.06.09.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 09:18:10 -0700 (PDT) Message-ID: <53690B4B.5060507@nthpermutation.com> Date: Tue, 06 May 2014 12:18:19 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070709000600090405040106" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bz0xjEDF7z-2-czFQssvAXOZV_U Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:18:21 -0000 This is a multi-part message in MIME format. --------------070709000600090405040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In line On 5/6/2014 1:32 AM, Joseph Salowey (jsalowey) wrote: > On Apr 29, 2014, at 10:46 AM, Michael StJohns wrote: > >> On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote: >>> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github. >> Sorry - I'm coming late here. Does this also imply the complete elimination of the integrity only cipher suites? >> > [Joe] Its possible to have AEAD modes that provide only authentication, however I don't think that the currently defined AEAD ciphers support authentication only so its possible that some modification may need to be made to support this. Actually, both CCM and GCM support authentication only. Simply provide AAD and no plain or cipher text. But what I probably should have asked was whether we were obsoleting all of the current integrity only suites (and I think from what I read in other responses the answer is yes), and if so what we were going to replace them with? I don't know that CCM and GCM will be able to fill the existing niches, and I don't know that the composited AEAD functions make sense for this use. > >> With respect to the AEAD approach and with respect to composited AEAD cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for example), does this also imply that the key expansion phase will never be used to generate MAC keys, and that the cipher suite has to provide whatever mechanisms that are required to split the AEAD key into underlying encryption/integrity keys if required? >> > [Joe] Yes, the cipher suite would be responsible for deriving the appropriate keys from the key material it is given. Note for action: Provide a generic method for use with composited functions that's related to the way session keys are derived. Rationale: KDFs are *hard* to get right. > > >> Next (reading from the commited editors copy), this refers to 5116 which uses a one-size fits all approach that doesn't really fit all sizes, especially for composited AEAD. E.g. the draft describes this generally as an incrementing value. For AEAD suites that comply with 5116, that should be part of the suite specification - not TLS. For TLS, this just needs to be an normatively opaque, per-message field. Instead, place an Informative section which recommends how to do this with AEAD suites that currently exist. >> > [Joe] I think I'm missing your point here. I thought the existing cipher suites did define how the nonce is generated and the TLS document just provides some guidance on nonce generation. From the document : > AEAD ciphers take as input a single key, a nonce, a plaintext, and > "additional data" to be included in the authentication check, as > described in Section 2.1 of [RFC5116] > . It's unclear to me that a composited AEAD function will always take a nonce. And that the IV from one message to the next will be a simple increment of an IV field (e.g. if the underlying encryption mode for a composited AEAD function is something like CBC then the IV really needs to be more random). The section in the editors draft 6.2.3.3 uses RFC5116 as its definition of how an AEAD cipher needs to look, and that was fine as long as there were other ways of looking at ciphers (stream, block), but its unclear this section is generic enough to deal with anything except CCM and GCM style AEAD ciphers. My point with this section is to remove 5116 language, and abstract the hell out of the AEAD interface into something that will work with more than just CCM and GCM. Or at least I believe this has to be done if all but AEAD ciphers are being removed. >> And finally, as I've noted many times before, deriving IV/nonce material from the master_secret at the same time as deriving keys is not securely supportable in hardware. >> > [Joe] So currently with AES-GCM and AES-CCM then nonce is partially derived from the Client and Server IV. If I remember correctly the TLS derivation by splitting up the derived key material into secret keys and IVs is problematic. Can this part of the problem be solved by changing the way TLS derives keys and IVs? Yup. I've got a current draft on that. The issue here is mostly about how the IV/nonce is generated as a keyed PRNG approach is problematic in a number of ways. Mike >>> Joe >>> --------------070709000600090405040106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
In line

On 5/6/2014 1:32 AM, Joseph Salowey (jsalowey) wrote:
On Apr 29, 2014, at 10:46 AM, Michael StJohns <msj@nthpermutation.com> wrote:


On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote:

The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github.

Sorry - I'm coming late here.  Does this also imply the complete elimination of the integrity only cipher suites?


[Joe] Its possible to have AEAD modes that provide only authentication, however I don't think that the currently defined AEAD ciphers support authentication only so its possible that some modification may need to be made to support this.

Actually, both CCM and GCM support authentication only.  Simply provide AAD and no plain or cipher text.

But what I probably should have asked was whether we were obsoleting all of the current integrity only suites (and I think from what I read in other responses the answer is yes), and if so what we were going to replace them with?  

I don't know that CCM and GCM will be able to fill the existing niches, and I don't know that the composited AEAD functions make sense for this use.



With respect to the AEAD approach and with respect to composited AEAD cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for example), does this also imply that the key expansion phase will never be used to generate MAC keys, and that the cipher suite has to provide whatever mechanisms that are required to split the AEAD key into underlying encryption/integrity keys if required?


[Joe] Yes, the cipher suite would be responsible for deriving the appropriate keys from the key material it is given.

Note for action:  Provide a generic method for use with composited functions that's related to the way session keys are derived.  Rationale:  KDFs are *hard* to get right.




Next (reading from the commited editors copy), this refers to 5116 which uses a one-size fits all approach that doesn't really fit all sizes, especially for composited AEAD. E.g.  the draft describes this generally as an incrementing value.  For AEAD suites that comply with 5116, that should be part of the suite specification - not TLS.  For TLS, this just needs to be an normatively opaque, per-message field.    Instead,  place an Informative section which recommends how to do this with AEAD suites that currently exist.


[Joe] I think I'm missing your point here. I thought the existing cipher suites did define how the nonce is generated and the TLS document just provides some guidance on nonce generation.

From the document :

AEAD ciphers take as input a single key, a nonce, a plaintext, and “additional data” to be included in the authentication check, as described in Section 2.1 of [RFC5116].

It's unclear to me that a composited AEAD function will always take a nonce.  And that the IV from one message to the next will be a simple increment of an IV field (e.g. if the underlying encryption mode for a composited AEAD function is something like CBC then the IV really needs to be more random).

The section in the editors draft 6.2.3.3 uses RFC5116 as its definition of how an AEAD cipher needs to look, and that was fine as long as there were other ways of looking at ciphers (stream, block), but its unclear this section is generic enough to deal with anything except CCM and GCM style AEAD ciphers.  

My point with this section is to remove 5116 language, and abstract the hell out of the AEAD interface into something that will work with more than just CCM and GCM.  Or at least I believe this has to be done if all but AEAD ciphers are being removed.

And finally, as I've noted many times before, deriving IV/nonce material from the master_secret at the same time as deriving keys is not securely supportable in hardware.


[Joe]  So currently with AES-GCM and AES-CCM then nonce is  partially derived from the Client and Server IV.   If I remember correctly the TLS derivation by splitting up the derived key material into secret keys and IVs is problematic.  Can this part of the problem be solved by changing the way TLS derives keys and IVs?

Yup.  I've got a current draft on that.  The issue here is mostly about how the IV/nonce is generated as a keyed PRNG approach is problematic in a number of ways.

Mike
Joe
--------------070709000600090405040106-- From nobody Tue May 6 09:20:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C8E1A00A2 for ; Tue, 6 May 2014 09:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_HXRgSiGinm for ; Tue, 6 May 2014 09:20:41 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8F1A0173 for ; Tue, 6 May 2014 09:20:41 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s46GKWE4021425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 18:20:32 +0200 (MEST) In-Reply-To: <5368DAED.3020000@gmail.com> To: Rene Struik Date: Tue, 6 May 2014 18:20:32 +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: <20140506162032.AEC6A1ACF7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f4jivrYmfTlmFeYC1-IbJXoizFc Cc: "tls@ietf.org" Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:20:45 -0000 I can not correlate your most recent response to the prior question: >Michael StJohns wrote: >> >> Sorry - I'm coming late here. Does this also imply the complete >> elimination of the integrity only cipher suites? I understand this to refer to these cipher suites: CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; which provide authentication PLUS integrity, but no confidentiality. Rene Struik wrote: > > In general, an AEAD mode takes as input two strings a and m and a key k, > and authenticates a and m, while encrypting m. If m is the empty string, > this results in an authentication-only mode. > > Thus, AEAD modes can be used to provide suitable combinations of > authentication and/or encryption. Examples hereof include the GCM mode > and CCM mode. Now this seems to refer to an idea to provide only (initial) authentication, but no integrity protection of the actual application data (m). -Martin From nobody Tue May 6 09:24:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B131A01AE for ; Tue, 6 May 2014 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9B16n5EJc0X for ; Tue, 6 May 2014 09:24:18 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id D551F1A01A6 for ; Tue, 6 May 2014 09:24:17 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z60so3725961qgd.4 for ; Tue, 06 May 2014 09:24:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eziJKUM7EHRpAi7Ria2+VH3j3wfb0MxwTF9KrnlZBZk=; b=kpkT7oCWrMnIGJ859m8TS3YSNyVQ0J4U5zjv4T/eGdVAkvD0W8FzLboern8iGxTzie 8vA+BMXlX/6FeiOuZjq4sz7Rk8u2gatUACl22Q5mXDHGgvmaJXYMjSGu3ZioNoT/8S6T Wcj3CIOqOVv4hE7zcolbf/c6aDswvgQFIHZsvEW21ubDqjk0O9MA1GmzPcDzfSlZ4zcY La6HCfvFD0I2/UDILH7BrZL9g8LCn0fVat4xFoqBoiGemlbajsvY0Z67EgbH76teHB4D tA1O1yXouXLcnB26Me/hFvVLB+xJa9R7Nbeazp6QoZj3BVdDLFJ7I5MoBCv6mL5ptqt2 YtuA== X-Gm-Message-State: ALoCoQklnl2VAI+cMCEQNVini4+7C+4gStTeb9YdVrSTNec16CtoC9sioz1uUK1pRRtYMfJeTe6j X-Received: by 10.224.79.143 with SMTP id p15mr56316873qak.57.1399393453717; Tue, 06 May 2014 09:24:13 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id j7sm24316868qab.27.2014.05.06.09.24.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 09:24:13 -0700 (PDT) Message-ID: <53690CB5.1060704@nthpermutation.com> Date: Tue, 06 May 2014 12:24:21 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , Rene Struik References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> <5368DAED.3020000@gmail.com> <5528AE3F-2483-42EA-949F-E3FC6774A4FC@cisco.com> In-Reply-To: <5528AE3F-2483-42EA-949F-E3FC6774A4FC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IMP_O8IbltSv5fDOY8x8GNcKDcE Cc: "tls@ietf.org" Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:24:19 -0000 On 5/6/2014 11:11 AM, Joseph Salowey (jsalowey) wrote: > On May 6, 2014, at 5:51 AM, Rene Struik wrote: > >> Hi Joe: >> >> In general, an AEAD mode takes as input two strings a and m and a key k, and authenticates a and m, while encrypting m. If m is the empty string, this results in an authentication-only mode. >> >> Thus, AEAD modes can be used to provide suitable combinations of authentication and/or encryption. Examples hereof include the GCM mode and CCM mode. >> > [Joe] Yes, but I don't think any of the defined cipher suites for AES-GCM or AES-CCM support an authentication-only mode. If authentication-only support is desired then additional cipher suites would have to be defined. If a message consists of 100 bytes of AAD and 0 bytes of plaintext, then the output of an AEAD cipher is the integrity tag over the 100 bytes of AAD and no cipher text. That's pretty much authentication-only. Not optimized for that though. Mike From nobody Tue May 6 09:35:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CD11A017E for ; Tue, 6 May 2014 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHgshBNNpu7D for ; Tue, 6 May 2014 09:35:44 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5FB81A0189 for ; Tue, 6 May 2014 09:35:42 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so3118751qaq.17 for ; Tue, 06 May 2014 09:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=beQIXPTkYPpOWZUo9HDb1+rsccAwwMRaOKFOKLCAqEQ=; b=SJAiCsOTwvOLAGvNtfRXRk8kxq7PHWO0QNhLwP+gApTIT6w70BiTMTceq/krbLU0Cr tjJ/Zsm7xvEaL3XqTAErlS/gn+EYUTyssexzILlW+SWHMA1WIjNNXrTjwPByKSySL4+y +UkwmD66a9/9gKwL+QAAjZB7iMFdzA/lF7J1TyXF5CT8vjMkjnup80/93Mto3GZXBCop I0sfxJ+ujIMkjPNRjnutM9MLo5oLDOu2SJ4PlelOnk7+swm1qIJAukyIZD13qBlWWXh2 WNO+cAxGfxgOKMRvqf6KFuMikKrvXTG26N1I1S3JxnSiKUj8zCPHoApz1l+Vi7T3XdlC kP2g== X-Gm-Message-State: ALoCoQkNVxulCrlcrE1y3ZaO/6FC6NHPXWWOo4O7r8AOCYSN0KnJd+J+DqoAi3Tooo3UNZBQXxvq X-Received: by 10.224.35.209 with SMTP id q17mr57206308qad.9.1399394138802; Tue, 06 May 2014 09:35:38 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id z4sm24378286qas.8.2014.05.06.09.35.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 09:35:38 -0700 (PDT) Message-ID: <53690F62.408@nthpermutation.com> Date: Tue, 06 May 2014 12:35:46 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mrex@sap.com, Rene Struik References: <20140506162032.AEC6A1ACF7@ld9781.wdf.sap.corp> In-Reply-To: <20140506162032.AEC6A1ACF7@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a4XLJ_9s3IW-s39UpLRvU0yZF_8 Cc: "tls@ietf.org" Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:35:46 -0000 On 5/6/2014 12:20 PM, Martin Rex wrote: > I can not correlate your most recent response to the prior question: > >> Michael StJohns wrote: >>> Sorry - I'm coming late here. Does this also imply the complete >>> elimination of the integrity only cipher suites? > I understand this to refer to these cipher suites: > CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; > CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; > > which provide authentication PLUS integrity, but no confidentiality. That and about 2 dozen others that are WITH_NULL. > > Rene Struik wrote: >> In general, an AEAD mode takes as input two strings a and m and a key k, >> and authenticates a and m, while encrypting m. If m is the empty string, >> this results in an authentication-only mode. >> >> Thus, AEAD modes can be used to provide suitable combinations of >> authentication and/or encryption. Examples hereof include the GCM mode >> and CCM mode. > Now this seems to refer to an idea to provide only (initial) authentication, > but no integrity protection of the actual application data (m). Nope. AEAD ciphers provide integrity protection across the entire message, plaintext and associated data. So if the message consists only of associated data, that associated data data is still protected. (m) and (a) together are the application data, not solely (m). (m) is just the data to be encrypted. Mike > > -Martin > > From nobody Tue May 6 09:44:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCA91A0173 for ; Tue, 6 May 2014 09:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8L-a4eax9vi for ; Tue, 6 May 2014 09:44:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C775B1A0161 for ; Tue, 6 May 2014 09:44:38 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s46GiXfC002134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 6 May 2014 12:44:34 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s46GiVEb001892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 6 May 2014 12:44:32 -0400 Message-ID: <1399394671.30930.55.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org Date: Tue, 06 May 2014 18:44:31 +0200 In-Reply-To: <20140506152514.GY27883@mournblade.imrryr.org> References: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> <1399274903.2312.6.camel@dhcp-2-127.brq.redhat.com> <20140505170029.GA24821@roeckx.be> <1399367598.30930.12.camel@dhcp-2-127.brq.redhat.com> <20140506152514.GY27883@mournblade.imrryr.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/50TRR6vseVRmCNHL6l5kYHHwgZU Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:44:40 -0000 On Tue, 2014-05-06 at 15:25 +0000, Viktor Dukhovni wrote: > > I believe that this draft addresses the existing concerns with the DH > > ciphersuites I'm aware of, and would be very good if the TLS WG would > > adopt it. > Other collections of DHE groups work in a subgroup of order "q", > where log(q) ~ 2^{security factor}. This speeds up the arithmetic. > (Squares can be reduced modulo the much smaller q). I think the speed up in that case is because the exponent x is selected to be in the range (1,q-1). The modular reduction is again mod p. > Is there a > reason to avoid those? Problems with constant-time implementation? > Other concerns? This is another valid approach. Note however, that in the groups described in the draft there is a suggested key size which speeds the calculations similarly. regards, Nikos From nobody Tue May 6 10:09:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACCE1A01B9 for ; Tue, 6 May 2014 10:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scpWgRG8RvEz for ; Tue, 6 May 2014 10:09:23 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id DB51B1A01C0 for ; Tue, 6 May 2014 10:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=6gKXzUiPrE+hCl71CJt1WGCZwUxIqBBimBczm7pkeHU=; b=Jbyfmbp2b2vY8w2/Y6jDpVKO6jFOuidin5p9YzWicLiN8hx5ljkauTrkrH07zCqwvINx0uAezHQ75DCcnnRqdOwnPH6NHPEB2nK57nrBGUH0SFLpbSwosze2imxfEjgWfDxRRQNZ1pkRarpcXhUgUjxEVWLUnezUvsM/WnCQUAc=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Whir4-0002hQ-Fw; Tue, 06 May 2014 19:08:35 +0200 Message-ID: <5369172F.8090102@polarssl.org> Date: Tue, 06 May 2014 19:09:03 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael StJohns , "Joseph Salowey (jsalowey)" , Rene Struik References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> <5368DAED.3020000@gmail.com> <5528AE3F-2483-42EA-949F-E3FC6774A4FC@cisco.com> <53690CB5.1060704@nthpermutation.com> In-Reply-To: <53690CB5.1060704@nthpermutation.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8ai-reYpQrBpXtU-MEqXIc_zjKU Cc: "tls@ietf.org" Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 17:09:24 -0000 On 06/05/2014 18:24, Michael StJohns wrote: > On 5/6/2014 11:11 AM, Joseph Salowey (jsalowey) wrote: >> On May 6, 2014, at 5:51 AM, Rene Struik wrote: >> >>> Hi Joe: >>> >>> In general, an AEAD mode takes as input two strings a and m and a key k, and authenticates a and m, while encrypting m. If m is the empty string, this results in an authentication-only mode. >>> >>> Thus, AEAD modes can be used to provide suitable combinations of authentication and/or encryption. Examples hereof include the GCM mode and CCM mode. >>> >> [Joe] Yes, but I don't think any of the defined cipher suites for AES-GCM or AES-CCM support an authentication-only mode. If authentication-only support is desired then additional cipher suites would have to be defined. > > If a message consists of 100 bytes of AAD and 0 bytes of plaintext, then the output of an AEAD cipher is the integrity tag over the 100 bytes of AAD and no cipher text. That's pretty much authentication-only. > Sure, but as Joe said, within TLS you would need new ciphersuites for that. While AES-GCM and AES-CCM in general can do authentication-only, in TLS currently they can't because there is no way to include the payload in the AAD and to send it in the clear. Manuel. From nobody Tue May 6 10:16:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9541A019C for ; Tue, 6 May 2014 10:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbtGK_pnX5-0 for ; Tue, 6 May 2014 10:16:30 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id DD3711A0196 for ; Tue, 6 May 2014 10:16:29 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so3035505qcx.35 for ; Tue, 06 May 2014 10:16:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=u+SMkcBO13UAQ8z3cjlEqUHGwz8XFOQK+b5iATsO/40=; b=m68D48qBSkyHL+Qqwir/o9YhFNa+0s/ge4mV5TP5fy6yQQGXYzqvbQ5ZptXzGEPngj oWXGuUUuAeN6RzrqQT0OUwPLmw5FIW2AFhWTmIO9KWdHhlNj4vKBnknTmZlE+gx+MsBd y5SsBK9b1lbKgVcO/LA8m/i/QIya4I8S3Jk4nWQHAFTDguNEOYdbP28xz2DQQSvMIqRE LzESPCcQlY3jFJ4GGZihTobGaUfMKMd7FvWiRx8AKLu8PqsR2lD3btB+N3qB/mrPQGHH 2rMH35CjXNXR+H7sZD8pg2dkypY8VzUeSb5DpZfo8hKzWHPg5sfh23nNsbgAwX/Ve8MN HAoA== X-Gm-Message-State: ALoCoQnOfGJeUtpdwuaz0uWnnr3PcynGENaA+4IW34mrr3EcMgObGQTK6Vt1hDUu7NkpVnYV24Uw X-Received: by 10.140.43.139 with SMTP id e11mr6598375qga.39.1399396585719; Tue, 06 May 2014 10:16:25 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 21sm16421225qgh.23.2014.05.06.10.16.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 10:16:25 -0700 (PDT) Message-ID: <536918F1.7070502@nthpermutation.com> Date: Tue, 06 May 2014 13:16:33 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "Joseph Salowey (jsalowey)" , Rene Struik References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> <5368DAED.3020000@gmail.com> <5528AE3F-2483-42EA-949F-E3FC6774A4FC@cisco.com> <53690CB5.1060704@nthpermutation.com> <5369172F.8090102@polarssl.org> In-Reply-To: <5369172F.8090102@polarssl.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mPfMawemweueFhHalOoWJl7HHv4 Cc: "tls@ietf.org" Subject: Re: [TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 17:16:31 -0000 On 5/6/2014 1:09 PM, Manuel Pgouri-Gonnard wrote: > On 06/05/2014 18:24, Michael StJohns wrote: >> On 5/6/2014 11:11 AM, Joseph Salowey (jsalowey) wrote: >>> On May 6, 2014, at 5:51 AM, Rene Struik wrote: >>> >>>> Hi Joe: >>>> >>>> In general, an AEAD mode takes as input two strings a and m and a key k, and authenticates a and m, while encrypting m. If m is the empty string, this results in an authentication-only mode. >>>> >>>> Thus, AEAD modes can be used to provide suitable combinations of authentication and/or encryption. Examples hereof include the GCM mode and CCM mode. >>>> >>> [Joe] Yes, but I don't think any of the defined cipher suites for AES-GCM or AES-CCM support an authentication-only mode. If authentication-only support is desired then additional cipher suites would have to be defined. >> If a message consists of 100 bytes of AAD and 0 bytes of plaintext, then the output of an AEAD cipher is the integrity tag over the 100 bytes of AAD and no cipher text. That's pretty much authentication-only. >> > Sure, but as Joe said, within TLS you would need new ciphersuites for that. > While AES-GCM and AES-CCM in general can do authentication-only, in TLS > currently they can't because there is no way to include the payload in the AAD > and to send it in the clear. Ah. Sorry - didn't understand that was the point being made. And an absolutely correct one. So the crypto is the same, but how its used by TLS would change as TLS currently defines what part of the message is encrypted and what part is AAD. And to do that you'd have to define a variant of the current suites - OR - define some sort of extension to negotiate this. *bleah* Mike > > Manuel. > > From nobody Tue May 6 10:27:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435B21A0269 for ; Tue, 6 May 2014 10:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUQAmQwAGNLl for ; Tue, 6 May 2014 10:27:37 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0BC1A0268 for ; Tue, 6 May 2014 10:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=rxVc9ivBcQvDLAYyebq3TsWjR/AO39aQgfb99xw9D5U=; b=FnqBcWY/4jILGNRo52wHJgQ3lvQhQskEbADrg28RWjUVEIV94ZJ21QMRx3ytivuanEGh9y2D3/HVykuMd8oWovQx16dpKjP6A5BoTdk2MjXF7hf7sbjG1aQQTG1ZKW6TRQJFQLoVute/Rl/CI+EsGXB/FORIN7oGuJHp5CVJPXI=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Whj8k-0002j2-Cu; Tue, 06 May 2014 19:26:52 +0200 Message-ID: <53691B7B.3070100@polarssl.org> Date: Tue, 06 May 2014 19:27:23 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael StJohns , "Joseph Salowey (jsalowey)" References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> <53690B4B.5060507@nthpermutation.com> In-Reply-To: <53690B4B.5060507@nthpermutation.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WOrjhXDEXzrsir3zvBmY_pHMfG8 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 17:27:38 -0000 On 06/05/2014 18:18, Michael StJohns wrote: > But what I probably should have asked was whether we were obsoleting all > of the current integrity only suites (and I think from what I read in > other responses the answer is yes), and if so what we were going to > replace them with? > > I don't know that CCM and GCM will be able to fill the existing niches, > and I don't know that the composited AEAD functions make sense for this use. > It seems to me there should be no problem defining new functions NULL-HMAC-SHAXXX fitting the the AEAD interface (though the "E" would not really mean encryption) that would do exactly the same as the current NULL ciphersuites. Am I missing something? > From the document : > >> AEAD ciphers take as input a single key, a nonce, a plaintext, and >> "additional data" to be included in the authentication check, as >> described in Section 2.1 of [RFC5116] >> . > > It's unclear to me that a composited AEAD function will always take a > nonce. Not taking a nonce can probably be seen as taking a nonce of length zero. So, AEAD constructs without nonces would define SecurityParameters.record_iv_length and SecurityParameters.fixed_iv_length as 0. > And that the IV from one message to the next will be a simple > increment of an IV field (e.g. if the underlying encryption mode for a > composited AEAD function is something like CBC then the IV really needs > to be more random). > I may be misunderstanding the document, but I'm under the impression that incrementing the IV (or a field inside it) is only a suggestion. More precisely: > Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD > operation is constructed, seems to imply an AEAD suite can specify another method. > My point with this section is to remove 5116 language, and abstract the > hell out of the AEAD interface into something that will work with more > than just CCM and GCM. Or at least I believe this has to be done if all > but AEAD ciphers are being removed. > I agree that we should really make sure that the AEAD interface used covers all the constructs one might want to use. But right now I don't see where more generality would be needed. Manuel. From nobody Tue May 6 11:48:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD271A0234 for ; Tue, 6 May 2014 11:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-hmpth1wbbs for ; Tue, 6 May 2014 11:48:30 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 989701A01BB for ; Tue, 6 May 2014 11:48:30 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id c41so1053497yho.22 for ; Tue, 06 May 2014 11:48:26 -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:content-type; bh=/LqpE6bYVZ/i03Ub/dZtPSupKgwFpE+qVZYvb2MG8ug=; b=hm8fzeOhhTG5wD8tsWaQZTo2kuDjFKvI1rBpCZr/FIsUdKBartT+ZQ7jF806WPS4N9 5s1XXpLw/YGcIOPvSkXG1wL5hJANZlRrjrOikSR1Om7P3GNBj9zKtm8cn4YxAGLUPA7G Xq8uZyDbdDAQGoTGk/uLwJj8EOwxI4+XjN1cBBGV6v6o4C0GBV0vwjm4umX8NZbYB0rV Fw5fROilEzTRjlmM0FGfHUP8WcbAD0lL+rdmUH0fphZBgeb4kLzGhMD9vgefox3MMB2F VlRx77qeRtDlU8dFPSYVj7ZP6wS3DpTfJnT/DLFe8VQIHslZyWX9f37CFbm47aYZNSIL Vzcw== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr59487795yhi.4.1399402106697; Tue, 06 May 2014 11:48:26 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 6 May 2014 11:48:26 -0700 (PDT) Date: Tue, 6 May 2014 11:48:26 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rzn1wQdlva-2Rv63v-c8s6fAdak Subject: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 18:48:32 -0000 Dear all, Do you know what your TLS configurations mean? If you use OpenSSL, probably not: apparently "HIGH" enables ADH ciphersuites. It does so before permitting AES128 with an authenticated ECDHE exchange. Sorting by strength puts DES ahead of AES128: I've got no idea how that happened. (Yes, DES: 3DES is indicated differently. Maybe it is really 3DES, but even so...). I haven't found the email yet, but someone indicated they saw this in the wild on the list, actually leading to ADH happening due to an interaction between this and another borked configuration. I've sort of singled out OpenSSL here. PolarSSL uses compile-time configuration, which in some circumstances doesn't work, but it at least provides a somewhat sensible configuration depending on how you build it.I've not looked at GnuTLS yet, or cryptlib. Actually configuring OpenSSL to do something reasonable requires writing something like EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5. Good luck coming up with that when you are overly busy, don't realize that asking for high security doesn't actually do what you want, and don't know anything about crypto. Part of the issue is that we've enabled dangerous options like NULL ciphers and anonymous DH, which very, very few people should ever use. The other part of the issue is software quality. But a third part of the issue is the lack of guidance, which UTA was supposedly going to address. So how do we fix this? Well, one thing we can do is ensure that the least secure options are reasonably secure, so if they are enabled it isn't a disaster. Authentication-only ciphersuites fail that test. I appreciate the performance issue, and yes, sometimes you don't need encryption. But I think the number of people who accidentally enabled ADH is an order of magnitude more than those who actually wanted it. Sincerely, Watson Ladd From nobody Tue May 6 11:54:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F0B1A023A for ; Tue, 6 May 2014 11:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtKmHJEUm9dt for ; Tue, 6 May 2014 11:54:10 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id E063A1A01C4 for ; Tue, 6 May 2014 11:54:09 -0700 (PDT) Message-ID: <53692FC2.1060009@akr.io> Date: Tue, 06 May 2014 19:53:54 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MskGq5DVz8VkwqEIZl1n9tVUTdw Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 18:54:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/05/2014 19:48, Watson Ladd wrote: > I think the number of people who accidentally enabled ADH is an > order of magnitude more than those who actually wanted it. +1. I never saw anyone enable ADH, NULL or EXPORT cipher suites actually on purpose. I have definitely seen people do it by accident. The mere presence of NULL ciphersuites is dangerous: someone might actually use them, and that's basically never a good idea. Take them out; keep them out; don't put them back in. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaS/CAAoJEOyEjtkWi2t6q34P/j5QX4BBRJLusLx3cevVdxmM JXHnhPDY+ovbHSs1XkASJAS4x/k40IN2maj+8E47Me/ZsTriJd8659vq9jxQeTT4 f04TBYGphcBQupZg136CVcsA1WSFiWo1UfXffW8oRAQfU2CpVdeKb/0IFLgQ64sa G37UAxFtKTnFVtrec1Q5tdwfSdc6nEP2zbzpaAVB96vqJuel/bNtOFQM44CriPQ3 LbtIX3MMh0qfBAxwmTwe9+YahzGuCxIAStHwJl4JD3ReTJHlo/lxlDNIVt46nkzv HYB3moJ1tDlzpFn0xWNQHrKcN5GtotktsV12Uyq91DvAd6U/CHQD13h9cO5OmCDT Sb+S+0OmHeXah6A0zBe7DSJS+yf4pqjQazFaQyP6z0SLdh4krhvKP2hGiuDvTMyf b2WVOmd1ThitIqoFYfS8VhpbEOFrUDl4y6LYAEJgqCET20BK5Qal0doENrsTE260 57oFR7wygJpc4Y5yGZ4sWfOqRuowbJm7ZSdYguMv2VuS84M3BdhFHaitYyrEbZRR 9r6uuZR7d+VIR9nhLYXTFK9I4B2DDr6joLaVTzDB4W2tf6xHL2RsIRXnwCj3UdAQ XOHKtnQ+RCsHCUUetKsOx8Arc7IQb5R4f/qPF3bvhWWc4Q7dJevXcViz7eWaJ9MZ BK5q7JpBLXskyfIpToPR =DOKC -----END PGP SIGNATURE----- From nobody Tue May 6 12:34:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633151A03EB for ; Tue, 6 May 2014 12:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvNGuyTOlj4E for ; Tue, 6 May 2014 12:33:59 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id A23711A03E0 for ; Tue, 6 May 2014 12:33:59 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 586C21DFFD; Tue, 6 May 2014 19:33:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1399404834; bh=I1WqQdicMGxVKudljSBELroQECJTAreILbWNIWbq8LE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MzFY/lr3LmQQMhTY6RbDQ3feUbJEE3tx3mas3ehbmOnQXCNqDmz9XP+EFwKChh4KF nNLc7AFwdP2+9pYO07vF1ACmegm0yX+T8yB+1UPVatCiASLZ+exMt2zv+q405OzKmL Gwr94xRmpVzS9Ad/NRrE0dPo17j+vQqMbtry1RsM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id DF6A26001D; Tue, 6 May 2014 19:30:34 +0000 (UTC) From: James Cloos To: "tls\@ietf.org" In-Reply-To: (Watson Ladd's message of "Tue, 6 May 2014 11:48:26 -0700") References: User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 06 May 2014 15:30:34 -0400 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:140506:"tls\@ietf.org"::UlvzfEj5iAtIG6Jo:0CcBqh X-Hashcash: 1:30:140506:tls@ietf.org::WYcQrRJlHLziRMRj:00001dcbb X-Hashcash: 1:30:140506:watsonbladd@gmail.com::nvmOP4mOLfjEJLTv:000000000000000000000000000000000000000lHBDx Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6ecDJj00AZwN3Hz83sMFcQ8gHmc Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 19:34:01 -0000 >>>>> "WL" == Watson Ladd writes: WL> Do you know what your TLS configurations mean? If you use OpenSSL, WL> probably not: apparently "HIGH" enables ADH ciphersuites. It does so WL> before permitting AES128 with an authenticated ECDHE exchange. Sorting WL> by strength puts DES ahead of AES128: I've got no idea how that WL> happened. (Yes, DES: 3DES is indicated differently. Maybe it is really WL> 3DES, but even so...). With openssl-1.1g, I see no DES from HIGH, only 3DES. But you have to look carefully to realise that. The SRP and PSK suites which match the regex /DES/ use CBC3 to specify triple des; all other openssl suites which match /DES/ use 3DES to specify triple des. Gnutls, OTOH, always uses 3DES_EDE_CBC for the suites, and 3DES-CBC for the cipher. NSS’s tstclnt uses single-letter flags rather than names, but documents the triple des options with EDE3 for the ssl2 suite and 3DES for the ssl3 suites it supports. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue May 6 15:13:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050C51A0573 for ; Tue, 6 May 2014 15:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, J_CHICKENPOX_74=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWxiLx17ND81 for ; Tue, 6 May 2014 15:13:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB01A049F for ; Tue, 6 May 2014 15:13:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1D11B2AA9FF; Tue, 6 May 2014 22:13:44 +0000 (UTC) Date: Tue, 6 May 2014 22:13:44 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140506221344.GB27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53692FC2.1060009@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Tam4dDVs4e_7MB9Jm9kXn90G58w Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:13:51 -0000 On Tue, May 06, 2014 at 07:53:54PM +0100, Alyssa Rowan wrote: > On 06/05/2014 19:48, Watson Ladd wrote: > > > I think the number of people who accidentally enabled ADH is an > > order of magnitude more than those who actually wanted it. > > +1. I never saw anyone enable ADH, NULL or EXPORT cipher suites > actually on purpose. I have definitely seen people do it by accident. The SMTP server that hosts your email runs Postfix: $ posttls-finger -lmay -c akr.io posttls-finger: Connected to entima.net[78.129.143.175]:25 posttls-finger: Anonymous TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits) posttls-finger: Server is anonymous When remote Postfix systems employ unauthenticated opportunistic TLS to send you email (smtp_tls_security_level = may), they and your server will preferrentially use ADH and AECDH cipher-suites. Because any encryption at all is better than sending cleartext email, both your server and the remote SMTP clients typically leave both EXPORT and LOW cipher-grades enabled. This may change in Postfix 2.12 as I've seen no recent evidence of any systems that only support export-grade crypto. So I am inclined to disable EXPORT and LOW by default starting with 2.12 in 2015. Postfix also supports the use of NULL ciphers for client-certificate authenticated delivery to LMTP over the loopback interface, though this is not on by default (lmtp_tls_mandatory_ciphers = null). By the way, though it is nice to see your server publishing TLSA records for SMTP, the DANE WG draft for SMTP specifies that only certificate usages DANE-TA(2) and DANE-EE(3) are to be used with SMTP. You're publishing PKIX-EE(1). $ posttls-finger akr.io posttls-finger: using DANE RR: _25._tcp.entima.net IN TLSA 1 1 1 53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46 posttls-finger: Connected to entima.net[78.129.143.175]:25 posttls-finger: entima.net[78.129.143.175]:25: depth=0 matched end entity public-key sha256 digest=53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46 posttls-finger: Verified TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) The reason posttls-finger verified this, is that Postfix implicitly maps PKIX-EE(1) to DANE-EE(3), because that's better than simply treating the TLSA RR as unusable. > The mere presence of NULL ciphersuites is dangerous: someone might > actually use them, and that's basically never a good idea. > > Take them out; keep them out; don't put them back in. Authenticated loopback IPC is a perfectly fine use-case for NULL cipher-suites. Don't confuse perfectly fine protocol capabilities with fragile user interfaces. The OpenSSL cipherlist is not an end-user interface, it is a configuration interface for developers. Applications need to expose higher-level application-specific configuration interfaces, and the better designed ones do. I, for one, am not surprised by HIGH including ADH cipher-suites. It is a good idea to read the documentation before cargo-cult cut/paste of cipherlist strings. HIGH refers only to the symmetric algorithm bit strength. It would not be a useful building-block if it did not represent an elementary property. The DEFAULT cipherlist in OpenSSL excludes aNULL and eNULL. Safe strictly stronger cipherlists that want to elicit server certificates need to start with "DEFAULT" and subtract: # High-grade authenticated ciphersuites only DEFAULT+HIGH # High-grade, sans MD5, DSS certs and RSA key exchange. DEFAULT:!LOW:!EXPORT:!MEDIUM:!MD5:!aDSS:!kRSA By the way mere use of a cipher suite that elicits certificates does not magically make authentication happen, there still needs to be some code for that too... -- Viktor. From nobody Tue May 6 15:23:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179881A0601 for ; Tue, 6 May 2014 15:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54D4y67n8lJy for ; Tue, 6 May 2014 15:23:29 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 90B851A049F for ; Tue, 6 May 2014 15:23:29 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 675DC202022 for ; Tue, 6 May 2014 15:23:25 -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=Q+x+rHEOR06B8AW5vRVi HKcuInU=; b=w7Tev0z3CiBncm7iRGw6NhibV+7ZH+IoAHaJ7gOpVTdwIRIuNo4t oOW7KVrWcxiaWbxOhSZMyRBeCnfP99ws94fVtW3We/QwvMnJ+bH7nNSHONqLC8+G WY0gOQ5SNCjiVwVGYfMZdW6iEco7p0UZiLsFfIr4vFJNCciLacI5DYo= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 12A99202018 for ; Tue, 6 May 2014 15:23:24 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so3647320wib.4 for ; Tue, 06 May 2014 15:23:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.221.8 with SMTP id qa8mr4424761wic.39.1399415003569; Tue, 06 May 2014 15:23:23 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 6 May 2014 15:23:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 May 2014 17:23:23 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/28kCZyZnuWLWHUkF1mr3s2L_USE Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:23:30 -0000 Banning anon ciphersuites is NOT a good idea. We have at least two uses for them (more assuming we retain renego): - channel binding with tls-unique CB - opportunistic security (as in the SAAG list thread on OS, and, of course, what some SMTP MTAs do) Nico -- From nobody Tue May 6 15:48:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ED11A0660 for ; Tue, 6 May 2014 15:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R038ZiFgZa3I for ; Tue, 6 May 2014 15:48:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8C31A0650 for ; Tue, 6 May 2014 15:48:51 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 22:48:47 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0939.000; Tue, 6 May 2014 22:48:46 +0000 From: Andrei Popov To: Alyssa Rowan , "tls@ietf.org" Thread-Topic: [TLS] The risk of misconfiguration Thread-Index: AQHPaVw1+uUO+uu4GEGictF7fUtCx5sz5lUAgAA88mA= Date: Tue, 6 May 2014 22:48:46 +0000 Message-ID: <8b505f49d3f846ddac8b26964e330622@BL2PR03MB419.namprd03.prod.outlook.com> References: <53692FC2.1060009@akr.io> In-Reply-To: <53692FC2.1060009@akr.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(189002)(199002)(479174003)(377454003)(13464003)(15975445006)(33646001)(92566001)(74662001)(31966008)(77096999)(74502001)(50986999)(99396002)(99286001)(19580395003)(19580405001)(85852003)(575784001)(83322001)(83072002)(86362001)(81542001)(54356999)(76576001)(81342001)(76482001)(79102001)(77982001)(101416001)(20776003)(64706001)(4396001)(76176999)(21056001)(2656002)(74316001)(46102001)(86612001)(80022001)(87936001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GSwuTDPrSfgF5zaf8JobOeZzt1Y Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:48:54 -0000 Here are a couple scenarios I'm aware of that require NULL ciphers: 1. Protocols that implement their own encryption, but run within TLS channe= ls (to get through middle boxes). Double encryption is wasteful, therefore = NULL ciphers can be negotiated in this case. 2. Various cases where confidentiality is not required, or is not achievabl= e by means of encryption (e.g. constrained devices sending out periodic pin= gs). However, it seems reasonable to disable NULL ciphers in the default configu= ration. I have nothing to say in support of the EXPORT ciphers:) Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan Sent: Tuesday, May 6, 2014 11:54 AM To: tls@ietf.org Subject: Re: [TLS] The risk of misconfiguration -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/05/2014 19:48, Watson Ladd wrote: > I think the number of people who accidentally enabled ADH is an order=20 > of magnitude more than those who actually wanted it. +1. I never saw anyone enable ADH, NULL or EXPORT cipher suites actually on purpose. I have definitely seen people do it by accident. The mere presence of NULL ciphersuites is dangerous: someone might actually= use them, and that's basically never a good idea. Take them out; keep them out; don't put them back in. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaS/CAAoJEOyEjtkWi2t6q34P/j5QX4BBRJLusLx3cevVdxmM JXHnhPDY+ovbHSs1XkASJAS4x/k40IN2maj+8E47Me/ZsTriJd8659vq9jxQeTT4 f04TBYGphcBQupZg136CVcsA1WSFiWo1UfXffW8oRAQfU2CpVdeKb/0IFLgQ64sa G37UAxFtKTnFVtrec1Q5tdwfSdc6nEP2zbzpaAVB96vqJuel/bNtOFQM44CriPQ3 LbtIX3MMh0qfBAxwmTwe9+YahzGuCxIAStHwJl4JD3ReTJHlo/lxlDNIVt46nkzv HYB3moJ1tDlzpFn0xWNQHrKcN5GtotktsV12Uyq91DvAd6U/CHQD13h9cO5OmCDT Sb+S+0OmHeXah6A0zBe7DSJS+yf4pqjQazFaQyP6z0SLdh4krhvKP2hGiuDvTMyf b2WVOmd1ThitIqoFYfS8VhpbEOFrUDl4y6LYAEJgqCET20BK5Qal0doENrsTE260 57oFR7wygJpc4Y5yGZ4sWfOqRuowbJm7ZSdYguMv2VuS84M3BdhFHaitYyrEbZRR 9r6uuZR7d+VIR9nhLYXTFK9I4B2DDr6joLaVTzDB4W2tf6xHL2RsIRXnwCj3UdAQ XOHKtnQ+RCsHCUUetKsOx8Arc7IQb5R4f/qPF3bvhWWc4Q7dJevXcViz7eWaJ9MZ BK5q7JpBLXskyfIpToPR =3DDOKC -----END PGP SIGNATURE----- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 6 16:30:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D13A1A0662 for ; Tue, 6 May 2014 16:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOiybh17yf2l for ; Tue, 6 May 2014 16:30:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB61A0643 for ; Tue, 6 May 2014 16:30:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E2BF02AA9FF; Tue, 6 May 2014 23:30:05 +0000 (UTC) Date: Tue, 6 May 2014 23:30:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140506233005.GF27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <8b505f49d3f846ddac8b26964e330622@BL2PR03MB419.namprd03.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b505f49d3f846ddac8b26964e330622@BL2PR03MB419.namprd03.prod.outlook.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NlQzYHQjLJC8kcz-T0OMvPe6Tx4 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 23:30:12 -0000 On Tue, May 06, 2014 at 10:48:46PM +0000, Andrei Popov wrote: > I have nothing to say in support of the EXPORT ciphers:) Yes, and throw in LOW as well: EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 These (EXPORT and LOW) fortunately seem to have some time ago outlived their useful life. They can I think be disabled, rather than offered at the bottom of the client cipherlist, without degrading even opportunistic security where handshake-failure leads to cleartext fallback. This would leave OpenSSL with eNULL, MEDIUM and HIGH. HIGH includes 3DES, presumably in part because this is a historical MUST implement for interoperability cipher-suite. In practice that role was and to some extent still is actually played by RC4. -- Viktor. From nobody Tue May 6 17:01:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB11A03D7 for ; Tue, 6 May 2014 17:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izm4-_FfASEV for ; Tue, 6 May 2014 17:01:54 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 196D51A0662 for ; Tue, 6 May 2014 17:01:54 -0700 (PDT) Message-ID: <536977E3.3000608@akr.io> Date: Wed, 07 May 2014 01:01:39 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> In-Reply-To: <20140506221344.GB27883@mournblade.imrryr.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f9WUgedhsdBjVO24F33vAZT89D8 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:01:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/05/2014 23:13, Viktor Dukhovni wrote: >>> I think the number of people who accidentally enabled ADH is >>> an order of magnitude more than those who actually wanted it. >> I never saw anyone enable ADH, NULL or EXPORT cipher suites >> actually on purpose. I have definitely seen people do it by >> accident. > When remote Postfix systems employ unauthenticated opportunistic > TLS to send you email (smtp_tls_security_level = may), they and > your server will preferrentially use ADH and AECDH cipher-suites. Touché! I take your point there. SMTP's a particularly painful usecase, one with OE being particularly valuable, and one I overlooked. As I've previously pointed out, I prefer scenarios where Mallory can't passively tell if we're negotiating opportunistically, so he can't selectively MITM without risk of detection. Using anon ciphersuites for OE may make Mallory's life a little easier than if we just don't hard-fail on self-signed/expired certificates and the like when negotiating OE. But I can see that also complicates things in its own way (as OE then looks like just not implementing it right, and Bob can't tell either). As far as Nico points out with channel binding/tls-unique and anon, that's kind of a bigger problem with the triple-handshake issue and all. Maybe there's a better solution for that altogether that doesn't need or use A(EC)DH? > ...I've seen no recent evidence of any systems that only support > export-grade crypto. So I am inclined to disable EXPORT and LOW > by default starting with 2.12 in 2015. I think that seems eminently sensible. > Postfix also supports the use of NULL ciphers for > client-certificate authenticated delivery to LMTP over the loopback > interface, though this is not on by default > (lmtp_tls_mandatory_ciphers = null). Others have also pointed out some use cases for NULL: client-certificate authenticated loopback APIs; constrained devices pinging; and those using TLS merely as a framing protocol to get through middle-boxes. Those all leave me scratching my head wondering why they're using TLS anyway: • One's running locally (and authenticating with slow cert signatures, and it's the bulk cipher that bugs them?); • One's too small to (but not too small to do x.509/ASN.1, RSA, etc? and not sending anything identifiable?); and, • One's apparently only pretending to use TLS (which makes NULL an intriguing choice to reveal to that untrusted middle-box; why not masq a more fun protocol? What about if it sees NULL and measures encrypted/compressed data and freaks out? Why not - gasp - *lie*?). Of course, it wouldn't be the first time people made odd decisions. > The OpenSSL cipherlist is ...um. The word I'd use would be: hairy. In practice, unfortunately way too hairy for the average developer; whence passing the buck to the average end-user; whence the average end-user taking the cipherlist as copypasta from the first Google result they found that actually worked. We've all seen the end results. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaXfjAAoJEOyEjtkWi2t67K0P/1S0BL5Md5ZkQupmeNby4430 quDTMM/ONxC3LD77zs2gtgFgZJOHxjVl6fLR5boHMxPI+gPvd97OQ2whXbgabjoq 4YpU9Do/xasYd/PAUobBxGr54Tomoz/IfarG6okxOVdWBXMCICrEHxy6+OqdxFOD hVo61zQWX/kspGfKoAA9DhnOGpaIyjAc8fiIIqUv2vENPlP6Hdiofdyho8dI4vQ/ bdqaGhL6ankRm/RbOrcYWbU1W8PULJOluOSFET2jYXXrIReFtk8d+AN4v5eea9HG xI5zVzMo5Am55syJAwVuh7YLNhtSgoAm7cb/dXVULVUoWgSQ4Wwn+v9u8oFF/fnV 7NFp2hvxU++WodjoYIG30lHgLvT3dy0fQlNHeP0k5TkdftUhM1tbMfAPQg23yNQ0 A1aBUGz4OILzG3vLsrWm8rDhXbmQVHPuyJutK1Ukc6uO3p/j0kjcNQnr6TisqFQm sUStx8wz7XuvpawfDpDZ+2CdHaKdWc8KLxV+2M+LLfD/vQDCveYWAr+HUsxduLkA f6CPOusw3Xv5ELlLq6wUE5e57CDhrU8EE/ywX/4iNMxEDpFJIMvEVeQUmT8vJtEu WjMq+faem59KLqUQIEl7MJg4CMRJ6lfxxrG2Ll0JvS+emyKbJ9ceGU4quyKI4LxG Q5Suh/mQW3G903/BS4SO =xeVJ -----END PGP SIGNATURE----- From nobody Tue May 6 17:25:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6B1A06C4 for ; Tue, 6 May 2014 17:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHuR3OuWIL7U for ; Tue, 6 May 2014 17:25:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36E1A0069 for ; Tue, 6 May 2014 17:24:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 604172AAA03; Wed, 7 May 2014 00:24:52 +0000 (UTC) Date: Wed, 7 May 2014 00:24:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507002452.GH27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536977E3.3000608@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n-4hsMu7NvDfYEQHljfiF3MV3gY Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:25:04 -0000 On Wed, May 07, 2014 at 01:01:39AM +0100, Alyssa Rowan wrote: > > The OpenSSL cipherlist is > > ...um. The word I'd use would be: hairy. > > In practice, unfortunately way too hairy for the average developer; > whence passing the buck to the average end-user; whence the average > end-user taking the cipherlist as copypasta from the first Google > result they found that actually worked. > > We've all seen the end results. We must not confuse implementation user-interface issues with protocol issues. The protocol supports many different use-cases. Interfaces for cipher selection in implementations are not protocol issues. The OpenSSL cipherlist interface is beginning to get some attention. That issue belongs on openssl-dev@openssl.org, not tls@ietf.org. -- Viktor. From nobody Tue May 6 17:39:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E411A071D for ; Tue, 6 May 2014 17:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84h5dYIH6beJ for ; Tue, 6 May 2014 17:39:25 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0EA1A072D for ; Tue, 6 May 2014 17:39:24 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id F23EE801A7; Wed, 7 May 2014 02:39:19 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 2168D8005B for ; Wed, 7 May 2014 02:39:19 +0200 (CEST) Message-ID: <536980B6.2000204@net.in.tum.de> Date: Wed, 07 May 2014 02:39:18 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <53692FC2.1060009@akr.io> In-Reply-To: <53692FC2.1060009@akr.io> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WJJXnZsDbVxAHLUgjwePyONOBs4 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:39:27 -0000 Hi, > The mere presence of NULL ciphersuites is dangerous: someone might > actually use them, and that's basically never a good idea. > > Take them out; keep them out; don't put them back in. While I concur for the general use cases of Web/mail etc., I have seen the NULL ciphers put to successful use for large-scale data transfer between high-performance computing clusters. The use was indeed intentional. R -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Tue May 6 18:09:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCD1A045F for ; Tue, 6 May 2014 18:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrgAXPc2MRVL for ; Tue, 6 May 2014 18:08:57 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E46781A03F8 for ; Tue, 6 May 2014 18:08:56 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so272947yha.13 for ; Tue, 06 May 2014 18:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jCt8/K0JFeKHpXOsrmJLWYprLTNIl79pPfu3SKmhv4I=; b=eBg0DwomjGx0wdBT9jvkjr40sq42/Kf3YIM2oMf0aFxp0WKu1EMeLpAvpCe3zSwC+V yTX9pNX3V3bbo5ZSsWM4OAwf7uz4LcB+8EzhsgyaiBNPFuy2c+yPGmMyHZfLYrbtp4Ky DbWqLhM1QagzMUxX9FONNRdkHz6foRFa0pjPA6fSP0ltgF5ATfUUZ6UAJ3itq8u4rQEx fhLxHOfA+xpjvx0JzI5MhGqaVUZpshYnhJ34PI/viJTRQIb4WmJiR7l0CqB0M9yvkELd lixHGOU/amFVWWPjRMzfgmuh2bMkC7vLpR0/tawzYXgVaqEKWF0bGiumEf49uyhChSrI J81g== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr61821389yhi.4.1399424932898; Tue, 06 May 2014 18:08:52 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 6 May 2014 18:08:52 -0700 (PDT) In-Reply-To: <20140507002452.GH27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> Date: Tue, 6 May 2014 18:08:52 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xul6CP7xo_yR6yEYGrH80GLi5dg Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 01:08:59 -0000 On Tue, May 6, 2014 at 5:24 PM, Viktor Dukhovni wrote: > On Wed, May 07, 2014 at 01:01:39AM +0100, Alyssa Rowan wrote: > >> > The OpenSSL cipherlist is >> >> ...um. The word I'd use would be: hairy. >> >> In practice, unfortunately way too hairy for the average developer; >> whence passing the buck to the average end-user; whence the average >> end-user taking the cipherlist as copypasta from the first Google >> result they found that actually worked. >> >> We've all seen the end results. > > We must not confuse implementation user-interface issues with > protocol issues. The protocol supports many different use-cases. > Interfaces for cipher selection in implementations are not protocol > issues. The OpenSSL cipherlist interface is beginning to get some > attention. That issue belongs on openssl-dev@openssl.org, not > tls@ietf.org. Agreed, but it's an example of the hazard that insecure modes present. OpenSSL is not an outlier: with 100+ possible ciphersuites, with strange omissions and inclusions, and completely lacking information about which curve to use, designing a good configuration system to pick TLS ciphersuites is hard. PolarSSL takes the exact opposite tack, forcing users to subset a single preference order. It is entirely possible that legitimately desired ciphersuites cannot be chosen in PolarSSL: I know they cannot be reordered. No matter how the choice is presented to end-users or application developers, so long as it is possible to misconfigure TLS, it will be misconfigured. You can blame the end user or the programmer or the library writer all you want, but unless a library is willing to forgo supporting null ciphers, they will be used inadvertently. Why include something that should virtually never be used, when using it has bad consequences? We've recognized the need for guidance on how to use TLS, hence formation of UTA. We're punting on implementation, although I recently got an email about the C standards body wanting to standardize APIs for networks, which, if they included TLS with a sane API would be wonderful. But the complexity that OpenSSL reveals is real: there is no way to support all possible combinations of ciphersuites without something this nasty to pick between them. Sincerely, Watson Ladd > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue May 6 19:00:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF51A02E3 for ; Tue, 6 May 2014 19:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaA1oN7Gyg-w for ; Tue, 6 May 2014 19:00:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4311A02F2 for ; Tue, 6 May 2014 19:00:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EDE612AA9FF; Wed, 7 May 2014 02:00:23 +0000 (UTC) Date: Wed, 7 May 2014 02:00:23 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507020023.GI27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KDnR75SH5j7fb060UIEHtbnVDXs Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:00:33 -0000 On Tue, May 06, 2014 at 06:08:52PM -0700, Watson Ladd wrote: > > We must not confuse implementation user-interface issues with > > protocol issues. The protocol supports many different use-cases. > > Interfaces for cipher selection in implementations are not protocol > > issues. The OpenSSL cipherlist interface is beginning to get some > > attention. That issue belongs on openssl-dev@openssl.org, not > > tls@ietf.org. > > Agreed, but it's an example of the hazard that insecure modes present. > No matter how the choice is presented to end-users or application > developers, so long as it is possible to misconfigure TLS, it will be > misconfigured. In Postfix the user chooses a "cipher-grade" that sets the floor on the set of enabled cipher-suites. The levels are monotone. This is a simple interface that is rather difficult to mess up. The underlying definitions of these grades is also configurable, but I strongly discourage users from attempting to touch these without expert advice. This has worked well for nearly a decade with no evidence of significant user confusion or misguided misconfiguration. User interfaces need to make the simple things easy and the complicated things possible. > You can blame the end user or the programmer or the > library writer all you want, but unless a library is willing to forgo > supporting null ciphers, they will be used inadvertently. Why include > something that should virtually never be used, when using it has bad > consequences? The above is just a rhetorical rant. Risk cannot be banned out of existence, but systems can be designed with greater safety in mind. > We've recognized the need for guidance on how to use TLS, hence > formation of UTA. We're punting on implementation, although I recently > got an email about the C standards body wanting to standardize APIs > for networks, which, if they included TLS with a sane API would be > wonderful. But the complexity that OpenSSL reveals is real: there is > no way to support all possible combinations of ciphersuites without > something this nasty to pick between them. The above is plainly false. Good systems offer many layers of controls, some for naive users some for experts. They have high and low level APIs, with the latter offering more fine-grained control when needed. OpenSSL should be improved not neutered. Software that only dumbs everything down is not progress, we need software that is both usable and flexible. -- Viktor. From nobody Tue May 6 20:32:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B21A021D for ; Tue, 6 May 2014 20:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WviMx_5dpC-D for ; Tue, 6 May 2014 20:32:50 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8E41A03FB for ; Tue, 6 May 2014 20:32:48 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id 29so379724yhl.19 for ; Tue, 06 May 2014 20: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:date:message-id:subject:from:to :content-type; bh=cjij/q7y/M1Xc/xhnJvkqr36NJa7MbPkGHOIRe7Zvu4=; b=oQd0lTYjd9kHkdCJdn95OkY1NjZ32WL9tMNEWzKuF9ZUrfHjjogMIC9LnueNT5okuq JaSqbsUjtpaxk4Sms31eTSLA+D+A7DqrW8tAz53WDVZkOTMFAS6nPmlEli89FN0sZ8q/ lMTgY24WqaxfbiDIRNO59YG+0aM/1k4dYsZgtNuJ9bJqd8Hf1dQ8fuwKLX7XogU416xN IYkCn46OHeWaYJWjIhPS7iDIbVp9e4lCIRgZ6M1Ukz26SrZEAk2oLyWn85oklH6ldDqa 7hMi5exneH9/fdYOP8+P4T5OLY9VJwAxHwf8blRRfersvYqsoUL4Eq6br2xeHZ+6L/NQ qo6w== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr62186676yhn.87.1399433564092; Tue, 06 May 2014 20:32:44 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 6 May 2014 20:32:43 -0700 (PDT) In-Reply-To: <20140507020023.GI27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> Date: Tue, 6 May 2014 20:32:43 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SgAnJAigNNaACMRsmjhjOpLl2qE Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 03:32:52 -0000 On Tue, May 6, 2014 at 7:00 PM, Viktor Dukhovni wrote: > On Tue, May 06, 2014 at 06:08:52PM -0700, Watson Ladd wrote: > >> > We must not confuse implementation user-interface issues with >> > protocol issues. The protocol supports many different use-cases. >> > Interfaces for cipher selection in implementations are not protocol >> > issues. The OpenSSL cipherlist interface is beginning to get some >> > attention. That issue belongs on openssl-dev@openssl.org, not >> > tls@ietf.org. >> >> Agreed, but it's an example of the hazard that insecure modes present. > >> No matter how the choice is presented to end-users or application >> developers, so long as it is possible to misconfigure TLS, it will be >> misconfigured. > > In Postfix the user chooses a "cipher-grade" that sets the floor > on the set of enabled cipher-suites. The levels are monotone. > This is a simple interface that is rather difficult to mess up. Actually, it makes the same mistake as OpenSSL does:enabling anonymous ciphers even when configured to send a server certificate and use 128 bit encryption, without an additional option set. (Source: http://www.postfix.org/TLS_README.html, search for the Server-Side Cipher Controls section) At least the documentation notes that this happens, and tells you the option you really need. Of course, the sad state of TLS for email prevents this from being a problem in practice. Postfix is one of the better-written applications out there, with a team that gets it. That does not apply to all applications. It doesn't even apply to mobile banking applications. > The underlying definitions of these grades is also configurable, > but I strongly discourage users from attempting to touch these > without expert advice. > > This has worked well for nearly a decade with no evidence of > significant user confusion or misguided misconfiguration. > > User interfaces need to make the simple things easy and the > complicated things possible. > >> You can blame the end user or the programmer or the >> library writer all you want, but unless a library is willing to forgo >> supporting null ciphers, they will be used inadvertently. Why include >> something that should virtually never be used, when using it has bad >> consequences? > > The above is just a rhetorical rant. Risk cannot be banned out of > existence, but systems can be designed with greater safety in mind. > >> We've recognized the need for guidance on how to use TLS, hence >> formation of UTA. We're punting on implementation, although I recently >> got an email about the C standards body wanting to standardize APIs >> for networks, which, if they included TLS with a sane API would be >> wonderful. But the complexity that OpenSSL reveals is real: there is >> no way to support all possible combinations of ciphersuites without >> something this nasty to pick between them. > > The above is plainly false. Good systems offer many layers of > controls, some for naive users some for experts. They have high > and low level APIs, with the latter offering more fine-grained > control when needed. OpenSSL should be improved not neutered. > Software that only dumbs everything down is not progress, we need > software that is both usable and flexible. I'm a Hobbsean: our role is to assure the safety of encrypted traffic, even if people can't do what they want as a result. How many ciphersuites do you really need? Not 314, soon to increase with the addition of ChaCha20+Poly1305. (Which surprisingly we do need: very few of the block ciphers are side channel resistant) This number is actually an underestimate: ECDH and ECDHE indicate curve support separately from ciphersuite. In TLS 1.3 we've decided to take a vast number to the woodshed: the question now is to reenable null encryption. Maybe it's possible to make a configuration system that enables a considerable number of these ciphersuites without letting people blow their leg off accidentally. Experimental evidence largely indicates otherwise. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue May 6 21:00:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635261A021A for ; Tue, 6 May 2014 21:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNcWMucx6Kih for ; Tue, 6 May 2014 21:00:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0745E1A0217 for ; Tue, 6 May 2014 21:00:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 88AE12AA9FF; Wed, 7 May 2014 03:59:57 +0000 (UTC) Date: Wed, 7 May 2014 03:59:57 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507035957.GM27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b9pCWRxWmYTdROhWuQQRT47GqCM Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 04:00:05 -0000 On Tue, May 06, 2014 at 08:32:43PM -0700, Watson Ladd wrote: > > In Postfix the user chooses a "cipher-grade" that sets the floor > > on the set of enabled cipher-suites. The levels are monotone. > > This is a simple interface that is rather difficult to mess up. > > Actually, it makes the same mistake as OpenSSL does:enabling anonymous > ciphers even when configured to send a server certificate and use 128 > bit encryption, without an additional option set. (Source: > http://www.postfix.org/TLS_README.html, search for the Server-Side > Cipher Controls section) What you say is mistake in Postfix is actually a mistake in your problem analysis. http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-8.2 use of anonymous ciphers in Postfix is not an accident, it is rather deliberate. > Of course, the sad state of TLS for email prevents this from being a > problem in practice. Actually TLS for email is not in such sorry shape as you might think. I bet a larger share of SMTP traffic is encrypted than with HTTP. Opportunistic TLS has a simpler deployment model. > > The above is plainly false. Good systems offer many layers of > > controls, some for naive users some for experts. They have high > > and low level APIs, with the latter offering more fine-grained > > control when needed. OpenSSL should be improved not neutered. > > Software that only dumbs everything down is not progress, we need > > software that is both usable and flexible. > > I'm a Hobbsean: our role is to assure the safety of encrypted traffic, > even if people can't do what they want as a result. How many > ciphersuites do you really need? There are different sets of "you". No single set of "you" needs all the ciphersuites, but collectively many are required in a general-purpose protocol. This is the price of success. - Some folks want ADH and AECDH - Some folks want NULL ciphers - Some folks want Suite-B - Japan wants CAMELLIA - Russia wants GOST - Korea wants SEED > In TLS 1.3 we've decided to take a vast > number to the woodshed: the question now is to reenable null > encryption. The Postfix "null" cipher grade offers ONLY NULL ciphers, and the other grades offer no NULL ciphers. Servers by default offer no NULL ciphers. It is rather difficult to enable NULL ciphers by accident and not notice. Both sides need to only offer NULL ciphers or else the handshake fails. > Maybe it's possible to make a configuration system that enables a > considerable number of these ciphersuites without letting people blow > their leg off accidentally. Experimental evidence largely indicates > otherwise. Experimental evidence based on an underfunded dominant toolkit. Which provides mostly just the low-level interfaces. This is starting to change. Breaking the protocol because OpenSSL is difficult to use right is not the right answer. Solve the right problem, work to improve OpenSSL. The Postfix to OpenSSL glue makes up for lack of higher level interfaces with ~10,000 lines of commented code: $ wc src/tls/*.[ch] | sort -k3nr 10594 40319 313491 total 2231 8228 62695 src/tls/tls_dane.c 1060 4717 36667 src/tls/tls_client.c 1209 4125 35031 src/tls/tls_misc.c 903 3873 31929 src/tls/tls_server.c 606 2393 19700 src/tls/tls.h 507 2119 16252 src/tls/tls_verify.c 593 2189 16242 src/tls/tls_scache.c 471 1466 12447 src/tls/tls_mgr.c 363 1632 11703 src/tls/tls_fprint.c 289 1276 8509 src/tls/tls_bio_ops.c 278 1135 7974 src/tls/tls_dh.c 245 858 7078 src/tls/tls_proxy_clnt.c 176 647 4885 src/tls/tls_certkey.c 160 648 4704 src/tls/tls_stream.c 169 573 4462 src/tls/tls_session.c 166 583 4119 src/tls/tls_prng_egd.c 142 516 3776 src/tls/tls_prng_exch.c 155 530 3732 src/tls/tls_prng_file.c 155 513 3681 src/tls/tls_prng_dev.c 94 294 2795 src/tls/tls_proxy_scan.c 119 410 2709 src/tls/tls_rsa.c 73 268 2139 src/tls/tls_scache.h 86 225 2133 src/tls/tls_proxy_print.c 81 311 2023 src/tls/tls_level.c 88 261 1814 src/tls/tls_seed.c 71 223 1808 src/tls/tls_mgr.h 50 154 1295 src/tls/tls_prng.h 54 152 1189 src/tls/tls_proxy.h One day when OpenSSL offers a much more complete high level interface, this code footpring might shrink. (Long from now, when we're ready to deprecate less capable OpenSSL versions). -- Viktor. From nobody Tue May 6 22:33:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53AF1A065B for ; Tue, 6 May 2014 22:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMlnZ6NwZXXB for ; Tue, 6 May 2014 22:32:59 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 32BD91A0656 for ; Tue, 6 May 2014 22:32:59 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id z6so66793yhz.20 for ; Tue, 06 May 2014 22:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rUVFAxHVRPso1o9lax7L9eiuUxGcpPV80HhKalaEb8M=; b=EXdeqSYeCSs6vIi+0m2s45FQXQzFhONbqZT+RBr5Vf3ZDK8bwGDmfB9xCJyNMXaXCl T6HJG2WFCpfzUpNva7cbtXIoA6lesLwOhGpkYUhqZkdRGJkVDpNATfOVDa65BQDxHEUM nNRjJ9x0jtdxq41U+un7x0cyPmAfbqyn3XARqBga845gEQiPIsfeVSGlm8qJb7hsFnbq VMu3Q3EE6SLtZ7tt3t4zmxjdHuwnFTdA/3zEvk4c6XmYPqJO3Qx9G7ZBNvcfWt7wd9TJ bGWmvTkgTVbCvXHjeCTRObsXz8vEenfKd7Qchw5GnRv0/sJ8gUmymBKqjxEs6pM8zgfL Im/g== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr63162910yhi.4.1399440775074; Tue, 06 May 2014 22:32:55 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 6 May 2014 22:32:54 -0700 (PDT) In-Reply-To: <20140507035957.GM27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> Date: Tue, 6 May 2014 22:32:54 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UA3XRy-X2_WLHHMM0Z7Ewh0BdUc Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 05:33:00 -0000 On Tue, May 6, 2014 at 8:59 PM, Viktor Dukhovni wrote: > On Tue, May 06, 2014 at 08:32:43PM -0700, Watson Ladd wrote: > >> > In Postfix the user chooses a "cipher-grade" that sets the floor >> > on the set of enabled cipher-suites. The levels are monotone. >> > This is a simple interface that is rather difficult to mess up. >> >> Actually, it makes the same mistake as OpenSSL does:enabling anonymous >> ciphers even when configured to send a server certificate and use 128 >> bit encryption, without an additional option set. (Source: >> http://www.postfix.org/TLS_README.html, search for the Server-Side >> Cipher Controls section) > > What you say is mistake in Postfix is actually a mistake in your > problem analysis. > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-8.2 > > use of anonymous ciphers in Postfix is not an accident, it is rather > deliberate. > >> Of course, the sad state of TLS for email prevents this from being a >> problem in practice. > > Actually TLS for email is not in such sorry shape as you might > think. I bet a larger share of SMTP traffic is encrypted than with > HTTP. Opportunistic TLS has a simpler deployment model. > Go walk outside. Ask someone "When you send email to someone, who can read it?". Compare their answer to the reality. So long as there is a difference between those two, you have a problem. At least with the web, we have a (somewhat) functioning PKI, and it's the protocol and implementations that are the real problem. (Interestingly DKIM ensures all email is signed, even without DANE, yet we've not been able to turn that into encrypting the connections between mail servers in 9 years of work. XMPP has a flag day in 13 days in which encryption will be on. Most servers will be using certificates.) Furthermore, in TLS 1.3 we've made changes to the protocol that have the side effect of removing everything but AES and Camellia. Yes, if you want to saturate a gigabit Ethernet cable using a 1.3 GHz processor, you may have a problem with encryption slowing things down. Is that worth the hazard null encryption presents? I'm not sure: I agree that (some) of the misconfiguration hazards are a result of the deplorable state of a major implementation, that is going to get massively changed, and so maybe we shouldn't worry too much. On the other hand people have turned them on by accident. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue May 6 22:58:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CDA1A049A for ; Tue, 6 May 2014 22:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gldgf0-JcOn8 for ; Tue, 6 May 2014 22:58:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 44F691A0231 for ; Tue, 6 May 2014 22:58:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A15882AA9FF; Wed, 7 May 2014 05:58:35 +0000 (UTC) Date: Wed, 7 May 2014 05:58:35 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507055835.GN27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q0m6jxqjMO1Hkp2kelACXXgHV7w Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 05:58:42 -0000 On Tue, May 06, 2014 at 10:32:54PM -0700, Watson Ladd wrote: > > Actually TLS for email is not in such sorry shape as you might > > think. I bet a larger share of SMTP traffic is encrypted than with > > HTTP. Opportunistic TLS has a simpler deployment model. > > Go walk outside. Some humility in areas in which you're not the domain expert may at times be appropriate. You say TLS for SMTP is in sorry state, this is not the case. It is simply opportunistic TLS, with which folks whose mental model of TLS is based on HTTPS are not sufficiently familiar: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09#section-1.3 > Ask someone "When you send email to someone, who can > read it?". We're talking about TLS in SMTP not who can or can't read stored email. Whether the man in the street knows it or not, a substantial fraction (estimated 20% and growing) of email traffic is encrypted in transit, just because both ends can simply turn on STARTTLS. I bet this fraction is larger than the fraction of HTTP traffic that is protected inside HTTPS. Yes, email is often stored by providers subject to a NSL. The same may well be true of your bank statement. Intelligence services are interesting in money movements, not just email. One might hope banks are not as cooperative with warrantless "metadata" as the telcos. > Compare their answer to the reality. So long as there is a > difference between those two, you have a problem. At least with the > web, we have a (somewhat) functioning PKI, and it's the protocol and > implementations that are the real problem. It only covers the sites that pay the PKI tax and the URLs that they bother to encrypt for clients willing to trust a few hundred CAs. This is NOT the majority of the traffic. Strong protection for some, no protection for most. Opportunistic TLS can scale to "some protection for most", largely by bypassing the PKI in question. > Furthermore, in TLS 1.3 we've made changes to the protocol that have > the side effect of removing everything but AES and Camellia. Yes, if > you want to saturate a gigabit Ethernet cable using a 1.3 GHz > processor, you may have a problem with encryption slowing things down. TLS 1.3 is not a done deal yet. > Is that worth the hazard null encryption presents? I'm not sure: I > agree that (some) of the misconfiguration hazards are a result of the > deplorable state of a major implementation, that is going to get > massively changed, and so maybe we shouldn't worry too much. Now we get to focus on solving the right problem. -- Viktor. From nobody Wed May 7 00:13:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAF21A0674 for ; Wed, 7 May 2014 00:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_32=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C92PkE3xrl_Z for ; Wed, 7 May 2014 00:13:49 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-05-out.s.azet.sk [91.235.53.55]) by ietfa.amsl.com (Postfix) with ESMTP id E026C1A028B for ; Wed, 7 May 2014 00:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1399446822; bh=Y2QBIxbAzh47f+ABjrcltinZs8dTTCxPtfzWJj67V5I=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EjwZ2katbsFIImyabUYs4RsEHQjqAhW87fsx7Fkc5sl/3Cd1fWDqMOgL2CQbsJnfu jVxEqymTljun3vShw9FE0KPeZ+gAQuVCtsP8g6wiekZWoKu3Tke6nEdbEjT4I0xMbQ sUMP/7vffvfrD4hMFcA6zFCUZNs8NlX37nQrGaEI= X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (tor.pm-ib.de [83.133.106.73]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 4EF9D67 for ; Wed, 7 May 2014 09:13:38 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 4EF9D67 Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk Message-ID: <5369DD21.6020301@azet.sk> Date: Wed, 07 May 2014 09:13:37 +0200 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> In-Reply-To: <20140506221344.GB27883@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2kmq-Esr_yp6xL_RtTSddpQPF5g Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:13:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07.05.2014 00:13, Viktor Dukhovni wrote: > On Tue, May 06, 2014 at 07:53:54PM +0100, Alyssa Rowan wrote: > >> On 06/05/2014 19:48, Watson Ladd wrote: >> >>> I think the number of people who accidentally enabled ADH is >>> an order of magnitude more than those who actually wanted it. >> >> +1. I never saw anyone enable ADH, NULL or EXPORT cipher suites >> actually on purpose. I have definitely seen people do it by >> accident. > > The SMTP server that hosts your email runs Postfix: > > $ posttls-finger -lmay -c akr.io posttls-finger: Connected to > entima.net[78.129.143.175]:25 posttls-finger: Anonymous TLS > connection established to entima.net[78.129.143.175]:25: TLSv1.1 > with cipher AECDH-AES256-SHA (256/256 bits) posttls-finger: Server > is anonymous > > When remote Postfix systems employ unauthenticated opportunistic > TLS to send you email (smtp_tls_security_level = may), they and > your server will preferrentially use ADH and AECDH cipher-suites. > > Because any encryption at all is better than sending cleartext > email, both your server and the remote SMTP clients typically > leave both EXPORT and LOW cipher-grades enabled. This may change > in Postfix 2.12 as I've seen no recent evidence of any systems > that only support export-grade crypto. So I am inclined to > disable EXPORT and LOW by default starting with 2.12 in 2015. > > Postfix also supports the use of NULL ciphers for > client-certificate authenticated delivery to LMTP over the loopback > interface, though this is not on by default > (lmtp_tls_mandatory_ciphers = null). > > By the way, though it is nice to see your server publishing TLSA > records for SMTP, the DANE WG draft for SMTP specifies that only > certificate usages DANE-TA(2) and DANE-EE(3) are to be used with > SMTP. You're publishing PKIX-EE(1). > > $ posttls-finger akr.io posttls-finger: using DANE RR: > _25._tcp.entima.net IN TLSA 1 1 1 > 53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46 > > posttls-finger: Connected to entima.net[78.129.143.175]:25 > posttls-finger: entima.net[78.129.143.175]:25: depth=0 matched end > entity public-key sha256 > digest=53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46 > > posttls-finger: Verified TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) > > The reason posttls-finger verified this, is that Postfix > implicitly maps PKIX-EE(1) to DANE-EE(3), because that's better > than simply treating the TLSA RR as unusable. > >> The mere presence of NULL ciphersuites is dangerous: someone >> might actually use them, and that's basically never a good idea. >> >> Take them out; keep them out; don't put them back in. > > Authenticated loopback IPC is a perfectly fine use-case for NULL > cipher-suites. Don't confuse perfectly fine protocol capabilities > with fragile user interfaces. > > The OpenSSL cipherlist is not an end-user interface, it is a > configuration interface for developers. Applications need to > expose higher-level application-specific configuration interfaces, > and the better designed ones do. > > I, for one, am not surprised by HIGH including ADH cipher-suites. > It is a good idea to read the documentation before cargo-cult > cut/paste of cipherlist strings. HIGH refers only to the > symmetric algorithm bit strength. It would not be a useful > building-block if it did not represent an elementary property. > > The DEFAULT cipherlist in OpenSSL excludes aNULL and eNULL. Safe > strictly stronger cipherlists that want to elicit server > certificates need to start with "DEFAULT" and subtract: > > # High-grade authenticated ciphersuites only DEFAULT+HIGH > > # High-grade, sans MD5, DSS certs and RSA key exchange. > DEFAULT:!LOW:!EXPORT:!MEDIUM:!MD5:!aDSS:!kRSA > > By the way mere use of a cipher suite that elicits certificates > does not magically make authentication happen, there still needs to > be some code for that too... > Your example # High-grade authenticated ciphersuites only DEFAULT+HIGH is incorrect because it selects also very weak ciphers EXP-DES-CBC-SHA, EXP-RC2-CBC-MD5, DES-CBC-SHA Try to run OpenSSL ciphers command: openssl ciphers 'DEFAULT+HIGH' DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:SEED-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-R S A-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA The correct selection is HIGH:!aNULL Always check your OpenSSL cipher configuration using the ciphers command. The command "openssl ciphers -v' will also display the properties of ciphers. -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTad0hXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOt5L8QAJcd9x5/PKw5d13GhgisPFIK 6w2Mhp22wEqn6hKLFmjxpBne6dVxsHQvpx81Xp6JQE761Za1Xpgz8JC+TaSeTNWJ kUcWPyIZrwAcZhw9EsBkeY/yI6+A3j3LD00gQ2H/4IP3wq8uoXDpynnmkedflcAC k49pVbqcgokVsXh8e/o8AQQ9YE0lpjYPmmSCPjNs3zt3FYENSGrstwA2nDvejOEi ATovb5ZQ7rLDP3aGDj04jiExCaZA5fkEexko8inZ7ioCF0OwOVIjOCNKIOhOWpdJ pKkOiW179OVFt7NY8lKvkWec1ex8zz114mdWCq2LIN44svrMcytaeas6uQoSlom0 VUVwzAyXvni1qVKHqHSBbDE3xOXtNhv9utvmpr3SbBk9BMZsJ15Re2bw5GdmgbJJ bf9/ydbGHuBs2Tk5eI0ZJRn79kXB6lx17oAAW/WQM/ewSjUmCCmkvCZ1sgFiiR+g iqnf8Bg/4i/vVdHzenVLRiwih2gk4u5eB5QDAwIXptkHmWugn7YOpD98FWDraKBs VibfqbwSmXo3UGbzRXRF6O76+7lgFzOPOToBqTtSp8n6gzdh8zKXtemVxuFUw8i4 +v5QwyCJG1M+WdElSj5S8+OmuZjQbFbcvR5QcMlcClEt9Shbp5GUMW00sF88cifE PRbYU93AErUriWxf1FFz =rmtB -----END PGP SIGNATURE----- From nobody Wed May 7 00:18:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A87A1A028B for ; Wed, 7 May 2014 00:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgST86uFJ2JY for ; Wed, 7 May 2014 00:18:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3933D1A016D for ; Wed, 7 May 2014 00:18:49 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s477Ii93026798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 May 2014 03:18:44 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s476e5ls017785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 7 May 2014 02:40:06 -0400 Message-ID: <1399444804.30930.61.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Wed, 07 May 2014 08:40:04 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k4ZhfH9lnmnughK-vDkiZ4BomZo Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:18:50 -0000 On Tue, 2014-05-06 at 11:48 -0700, Watson Ladd wrote: > I've sort of singled out OpenSSL here. PolarSSL uses compile-time > configuration, which in some circumstances doesn't work, but it at > least provides a somewhat sensible configuration depending on how you > build it.I've not looked at GnuTLS yet, or cryptlib. [...] > Actually configuring OpenSSL to do something reasonable requires > writing something like > EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5. > Good luck coming up with that when you are overly busy, don't realize > that asking for high security doesn't actually do what you want, and > don't know anything about crypto. Just because you saw a red car you cannot infer that all cars are red. As you describe it this clearly looks like an openssl problem and you need to report to the openssl developers, not this list. regards, Nikos From nobody Wed May 7 07:22:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58DD1A007C for ; Wed, 7 May 2014 07:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq-M7RcYeuzp for ; Wed, 7 May 2014 07:22:34 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 50F5C1A0311 for ; Wed, 7 May 2014 07:22:34 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so9191005wib.12 for ; Wed, 07 May 2014 07:22:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=COdKo1ORxJBeHQbWR+xNSrWFXhboNIZXUj5PYFBR7cM=; b=ExoEA8xsvzIZ+RcVmmBB8uLj5SmtFsGMfmpe3EF+aqEWV/dR9zYlc7JaXe5gIL9wGc lhMc4LE3EOZ9KX3OWdUp6/5s5nwRxrMem78toF9u77VAt9U4txPglVXUcXupW107aPUx yvWaYkOUG1l4kjAikc5KB+d6F77O0wknL4mQlmL/ryyucEmjz1iIIS8r4NGsFkBReWOA 4fg+Ne44J9SL8ggNP/XOIzmH4Wp/MkItWf4z1ALcxNLvJ4Q7hpGnld3Nw/a73oFuIvYG TIIgMxI/PIl00QMy4Yu+RxssLQLqdGc9BeJ53qTs6eyR7LWeyZdOnylKFSzPWAkOSDG6 PZUw== X-Gm-Message-State: ALoCoQnNqbBdRJmm7jED7/hz65Hg/3qh1VQtBbf9ewpQsP2hVS1Oyx42uDi8XYwIBXKSSzIKuH+D MIME-Version: 1.0 X-Received: by 10.194.175.70 with SMTP id by6mr38715518wjc.3.1399472549707; Wed, 07 May 2014 07:22:29 -0700 (PDT) Received: by 10.194.62.70 with HTTP; Wed, 7 May 2014 07:22:29 -0700 (PDT) In-Reply-To: <53692FC2.1060009@akr.io> References: <53692FC2.1060009@akr.io> Date: Wed, 7 May 2014 10:22:29 -0400 Message-ID: From: Warren Kumari To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WXTKnM4lBFRprDOWOZVwsnnmIRE Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:22:35 -0000 On Tue, May 6, 2014 at 2:53 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 06/05/2014 19:48, Watson Ladd wrote: > >> I think the number of people who accidentally enabled ADH is an >> order of magnitude more than those who actually wanted it. > > +1. I never saw anyone enable ADH, NULL or EXPORT cipher suites > actually on purpose. I have definitely seen people do it by accident. I've seen someone do it on purpose -- kinda.... Many years ago I was working for a large registrar -- we had an F5 load balancer that directed HTTP to one set of hosts, and HTTPS to another set. One day one of the sysadmins noticed that the HTTPS servers ran *much* hotter than the HTTP ones (for the same QPS). He came and asked me what to do about this, and I suggested that he go investigate and figure out why - I thought it would be a useful learning experience... Anyway, a month or two later we have some really weird network issue, so I fire up a sniffer -- and in one of the packets I see something that is fairly clearly a name and credit card number. Much panic ensues -- and then I discover how he has "solved" the issue -- yup, he has managed to disable everything, and then enable only NULL. He had no idea why, but he;d poked at things, and now the CPU on the HTTPS servers was much closer to the HTTP ones. Win! W > > The mere presence of NULL ciphersuites is dangerous: someone might > actually use them, and that's basically never a good idea. > > Take them out; keep them out; don't put them back in. > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJTaS/CAAoJEOyEjtkWi2t6q34P/j5QX4BBRJLusLx3cevVdxmM > JXHnhPDY+ovbHSs1XkASJAS4x/k40IN2maj+8E47Me/ZsTriJd8659vq9jxQeTT4 > f04TBYGphcBQupZg136CVcsA1WSFiWo1UfXffW8oRAQfU2CpVdeKb/0IFLgQ64sa > G37UAxFtKTnFVtrec1Q5tdwfSdc6nEP2zbzpaAVB96vqJuel/bNtOFQM44CriPQ3 > LbtIX3MMh0qfBAxwmTwe9+YahzGuCxIAStHwJl4JD3ReTJHlo/lxlDNIVt46nkzv > HYB3moJ1tDlzpFn0xWNQHrKcN5GtotktsV12Uyq91DvAd6U/CHQD13h9cO5OmCDT > Sb+S+0OmHeXah6A0zBe7DSJS+yf4pqjQazFaQyP6z0SLdh4krhvKP2hGiuDvTMyf > b2WVOmd1ThitIqoFYfS8VhpbEOFrUDl4y6LYAEJgqCET20BK5Qal0doENrsTE260 > 57oFR7wygJpc4Y5yGZ4sWfOqRuowbJm7ZSdYguMv2VuS84M3BdhFHaitYyrEbZRR > 9r6uuZR7d+VIR9nhLYXTFK9I4B2DDr6joLaVTzDB4W2tf6xHL2RsIRXnwCj3UdAQ > XOHKtnQ+RCsHCUUetKsOx8Arc7IQb5R4f/qPF3bvhWWc4Q7dJevXcViz7eWaJ9MZ > BK5q7JpBLXskyfIpToPR > =DOKC > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 7 08:57:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36851A0385 for ; Wed, 7 May 2014 08:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF8rQHOhFAM5 for ; Wed, 7 May 2014 08:57:56 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 267DA1A0379 for ; Wed, 7 May 2014 08:57:56 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id D19E52007F21E for ; Wed, 7 May 2014 08:57:51 -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=Vc1L6yNUwBlzr2QhYOA7 BIqgigM=; b=i9oUHEIy3INm6yzKVmhjgD0VYy2KhPp+rac6ekujdtj4icTiiwLF 36BBNKLnSEKj1sFmTBZVp/Jq5+Du5ACvj9yrtC9NKV9yCIVUBB2neEuCCIS38K/t kegHuERY2bl4ULZ6cT4xzYgGgmiaTduQSq6R8NAuDdDMw+BQPc8ruDk= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 86B122007F222 for ; Wed, 7 May 2014 08:57:51 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so1202885wev.19 for ; Wed, 07 May 2014 08:57:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr8487300wib.42.1399478270214; Wed, 07 May 2014 08:57:50 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 08:57:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 May 2014 10:57:50 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/joy5IGB_80J815I9DObhqE97FXE Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:57:57 -0000 Watson, How would you prevent PKI trust anchor set misconfiguration? Or the dreaded "give your money away to the bad guy?" pop-up? One can always get anon ciphersuites by just taking a peer's cert with no validation. There's no way to prove to them that you did validate their cert. Of course, that's a rather expensive way to get anon ciphersuites. Nico -- From nobody Wed May 7 10:05:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395DF1A0386 for ; Wed, 7 May 2014 10:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGSmI6OS9UtU for ; Wed, 7 May 2014 10:05:38 -0700 (PDT) Received: from sasl.smtp.pobox.com (sasl.smtp.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D25201A0385 for ; Wed, 7 May 2014 10:05:38 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id BC38E151C1; Wed, 7 May 2014 13:05:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=waPqwXoUlFEV aGyv+glL+tuD3gc=; b=Hj1LTnJYpKbNTNKzbhmr+jTz+b+2TIYWY/v+uQ1pPQJN rW1MijZkkY1QjirBHKqOURNlczZKN8WFDGRinSPXpxQXZkNYmHOpXSV4nHrXgtS7 yvLYE0Tcq4umZAQCDJKNvGSL8zUFTMbdzj6GmOI7GTFso0YYWSdjsKBrZbgEsfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=d4tKOV 1fP4SK3sr9aurGe+sammbd+jrZha1XVNJ09fn0guv8thmJi7+1+LAnagawuip8so ya4+tisbDNiAgvNSG2oin7YJBL6kBcEWualcXu4fRRmY9OUwSTd0Nf2NRYyot6+W fcvs0l2wVez/eASPy+h3Je/MqdIprI8ALXSuw= Received: from pb-sasl0.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id B11AB151C0; Wed, 7 May 2014 13:05:33 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl0.pobox.com (Postfix) with ESMTPSA id 06EDC151BF; Wed, 7 May 2014 13:05:30 -0400 (EDT) Message-ID: <536A67D9.2070302@pobox.com> Date: Wed, 07 May 2014 10:05:29 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CBBA30E8-D609-11E3-8F39-D2BAB895B7A1-38729857!pb-sasl0.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AFloW5gm27ZQhqw3wdl26u8SJMY Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:05:40 -0000 Nico Williams wrote: > > One can always get anon ciphersuites by just taking a peer's cert with > no validation. There's no way to prove to them that you did validate > their cert. Of course, that's a rather expensive way to get anon > ciphersuites. Yes, but it's riskier for a MitM to hope that a certificate isn't being checked. When they see "DH_anon" they know they can't be caught in the act. Mike From nobody Wed May 7 10:10:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E238E1A07D4 for ; Wed, 7 May 2014 10:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyY2GKCBecd8 for ; Wed, 7 May 2014 10:10:06 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 48D6E1A07D9 for ; Wed, 7 May 2014 10:10:02 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 49E31163B for ; Wed, 7 May 2014 10:09: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=61SU8D3DC+bygfIa2Rmi 2Kx8U5I=; b=XpCjdfrsOGaOYCck1YJK3BhXJRUTKmec1A4t8Yh+0byeFuiuYs6h 0yqc+MK73hOSrRCCny2evBTPOBwOewiTH5x42FKJ7kTXZxEQtzh/illXaEKRghs3 6z3fHb637TkWjh1rGMsYlm2N5ripejs1oc1HJhTbgV3Qb9IDgWpkix4= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id E85B01635 for ; Wed, 7 May 2014 10:09:57 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so1284660wgg.18 for ; Wed, 07 May 2014 10:09:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.143.109 with SMTP id sd13mr63529wjb.95.1399482596766; Wed, 07 May 2014 10:09:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 10:09:56 -0700 (PDT) In-Reply-To: <536A67D9.2070302@pobox.com> References: <536A67D9.2070302@pobox.com> Date: Wed, 7 May 2014 12:09:56 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VdMBcKEV_KIWbPbKx-4MFMhHGVc Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:10:08 -0000 On Wed, May 7, 2014 at 12:05 PM, Michael D'Errico wrote: > Nico Williams wrote: >> >> >> One can always get anon ciphersuites by just taking a peer's cert with >> no validation. There's no way to prove to them that you did validate >> their cert. Of course, that's a rather expensive way to get anon >> ciphersuites. > > > Yes, but it's riskier for a MitM to hope that a certificate isn't being > checked. When they see "DH_anon" they know they can't be caught in the > act. You're not listening. Some of us have uses for anon ciphersuites. Nico -- From nobody Wed May 7 10:20:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCB41A08A0 for ; Wed, 7 May 2014 10:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzuw8KJzh08Y for ; Wed, 7 May 2014 10:20:35 -0700 (PDT) Received: from sasl.smtp.pobox.com (sasl.smtp.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0761B1A01A6 for ; Wed, 7 May 2014 10:20:35 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id A733515252; Wed, 7 May 2014 13:20:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Uf6cL+0+Ghbv jwGpa3DhLFa3EcE=; b=nUe087c3L9RjeHJE599mFh3XNOiFfgbBwe+ofZRBPvLO Tvt6jDCZ1b4QL5MpD1F0sf09Jm0gZKKSCUIDEOYosE7K+GeR5AYTE7EcZSbVn/+r rWMSvocJDpF/1M9BemDq4swIb7LR4SXn4yo3V84aPzsRa9JfnfKh8ug421lpAOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=xyCVex z/dfDSyZOiTkyLnmEBFxA7CZbIMoQ1u9YqkmsVVjsw5rRBleTTxCrfKdFV33v+fL sd4fXtgjg1SdC6iKymyqXjRZ3U/Y/GSf126TzH1HBi8UKo61T1oe7zo6UG8RpU/4 kHT59hHL64NS/OK2zOTfM2+Vsty4yY5TzL5fg= Received: from pb-sasl0.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 9A12415251; Wed, 7 May 2014 13:20:30 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl0.pobox.com (Postfix) with ESMTPSA id 1C64E15250; Wed, 7 May 2014 13:20:28 -0400 (EDT) Message-ID: <536A6B5B.508@pobox.com> Date: Wed, 07 May 2014 10:20:27 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <536A67D9.2070302@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E26AA244-D60B-11E3-89DE-D2BAB895B7A1-38729857!pb-sasl0.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7S1CU492izs4aNYwGf-i3yBZxLs Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:20:36 -0000 > You're not listening. Some of us have uses for anon ciphersuites. I'm not against them. Was just pointing out that you can make it more difficult to MitM by appearing to do certificate validation. Mike From nobody Wed May 7 10:28:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06491A08AE for ; Wed, 7 May 2014 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxb9DE6sW5tw for ; Wed, 7 May 2014 10:28:29 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EDE8C1A08AF for ; Wed, 7 May 2014 10:28:28 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id EBA6D2007F220 for ; Wed, 7 May 2014 10:28:24 -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=8XrJ2g5UyyFGrRZxdtWM BA3VV+g=; b=Mufccn30B2JrhVIZCGya64JGBIyYplJV6CXsfH5UW7r3uWx2EgNR PnP0PS+EUITW3lDk1CHVDsmJXy5vm4SCiuLFsk0oc94egH1rblBaGpaTxzxirbKq Z5iHxXyz5Vf1yFCcvO0UAHFfc8grdL7p3Me+7nndk9tYEZKzlNqLoZk= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 9FD202007F221 for ; Wed, 7 May 2014 10:28:24 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so1347061wes.30 for ; Wed, 07 May 2014 10:28:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.187.107 with SMTP id fr11mr3084040wjc.70.1399483703635; Wed, 07 May 2014 10:28:23 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 10:28:23 -0700 (PDT) In-Reply-To: <536A6B5B.508@pobox.com> References: <536A67D9.2070302@pobox.com> <536A6B5B.508@pobox.com> Date: Wed, 7 May 2014 12:28:23 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DgJFHYK2qu4kUeRbnxqSBPjMNYw Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:28:30 -0000 On Wed, May 7, 2014 at 12:20 PM, Michael D'Errico wrote: >> You're not listening. Some of us have uses for anon ciphersuites. > > I'm not against them. Was just pointing out that you can make it > more difficult to MitM by appearing to do certificate validation. Without anon ciphersuites we'll end up with more self-signed cert usage. Then what? Ban those? OK, then we'll end up with some other arbitrary and equivalent convention. Can we stop now? From nobody Wed May 7 10:38:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0051A07A6 for ; Wed, 7 May 2014 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi-BPo6IPxe3 for ; Wed, 7 May 2014 10:38:35 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3FB1A081A for ; Wed, 7 May 2014 10:38:34 -0700 (PDT) Message-ID: <536A6F8C.7020702@akr.io> Date: Wed, 07 May 2014 18:38:20 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <536A67D9.2070302@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oXSzC1aIb3XVDfIQqlb38ThWIf0 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:38:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/05/2014 18:09, Nico Williams wrote: >> Yes, but it's riskier for a MitM to hope that a certificate isn't >> being checked. When they see "DH_anon" they know they can't be >> caught in the act. > You're not listening. Some of us have uses for anon ciphersuites. With the greatest respect, I'm simply not clear on why those uses are best addressed that way. For opportunistic encryption, at least with self-signed cert usage we can then softly migrate from opportunistic to DANE-EE pinning - and indeed that is the route SMTP has already taken, as Viktor's helpfully highlighted. Meanwhile aDH denies us that option, and broadcasts our MITM susceptibility to Mallory. tls-unique c/b may already need a big change anyway, thanks to triple-handshake, I gather? So, what use of anon_DH ciphersuites aren't addressed better by this method, especially given the very clear additional perpass risk of keeping them in TLS v1.3 that we've outlined here? How can we do better? - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTam+MAAoJEOyEjtkWi2t6xjMQAK5mEx6UszLFOyVmCR7OEm0t rGupMK6eShxc+rm2ETqUuNpaY79iii0OZ9e8XAohxol/aUWAyM0xYXd6yEEHt5Eh /yDvaNMZipADwzdOqaEzM/bN8mwPRxSTgQehE05wjimZN51vObf/t5Yn77ePfyg4 sQO4LV6CJ8YktEQ1EBUpxKoTmkxh4+ER6pvcuRGJGrFMo4Vs/YDjB3GrnP6i1ksQ irBRn+KrBFuOQonWieexzfnewVfhi3uhyEFFMt73mGn0sVCgLhD+S1AkSRzgRw3x oGmIkey6FiRWPM1IoO/C/bU9JxSQEdLErFmw2qJHHb+ElyYt8EoZ1JPM+hI1cRA/ EUA1pVZ34OWJueEYThRPeZOdgAfxqy985j/dtHVqP9/PJa9sneZm4KX8j5dK/p0q K6Y6g/4Yk4WcwskJIWcyLN7Xvjp659ca/+hCIEXPb6uBgLzzBWyE906whQsBsMvL X/2pcVpMiaPIMGBaND4g2WE6AVOdgubRdwp4GhM0V0Wgfv9jYN7aKy2OHmnbdoXZ BPlGQ74WZZ437XWCI/+2RVC9MKuE2COdiNMXx+T3ekJ7vst1+d0SXkRoJFFK43Sx bbJBWi/cxHmnkXdYoQLL904RVLHUS85T68FxZZ5uC9zAc6QURMoXRRify+4aY+mw pAwj4lAJkefJfWYcXqCx =K97j -----END PGP SIGNATURE----- From nobody Wed May 7 10:57:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B990A1A08B5 for ; Wed, 7 May 2014 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkfUzLRVgqOG for ; Wed, 7 May 2014 10:57:55 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 239141A08B2 for ; Wed, 7 May 2014 10:57:55 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id BD10626405D for ; Wed, 7 May 2014 10:57:50 -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=+mfG6pwxRZYHouExJ/85 VSVSRf4=; b=H9/fYlmAS9xfy+Ov3z/rSRyIzpz7nBTqTI2PEySUqOubcx4VpnhC 8NfvZcocaYVmAeFtAmKrpaL3ySRLvDvyhtwW5UakMwLz8jg0ycxZc5FBl6h48Dru rTxkpQ0qpPC/h0uTcHlobVMDt+FQZT2Tu9WKWm9n7niIAcYJ2BfaIF8= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 70463264059 for ; Wed, 7 May 2014 10:57:50 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so1348459wgh.17 for ; Wed, 07 May 2014 10:57:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr40110451wjx.8.1399485468882; Wed, 07 May 2014 10:57:48 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 10:57:48 -0700 (PDT) In-Reply-To: <536A6F8C.7020702@akr.io> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> Date: Wed, 7 May 2014 12:57:48 -0500 Message-ID: From: Nico Williams To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0DNPOJAXcF2YpBFrj4-sa14Qf0k Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:57:55 -0000 On Wed, May 7, 2014 at 12:38 PM, Alyssa Rowan wrote: > Meanwhile aDH denies us that option, and broadcasts our MITM > susceptibility to Mallory. Don't negotiate anon ciphersuites if they are of no use to you. Removing them because of misconfiguration fears is silly: there will always be possible misconfigurations. Please first address that argument. And the argument that I shouldn't have to pay for the additional CPU cycles needed to do pointless (in these use cases) PK. Nico -- From nobody Wed May 7 11:17:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D031A0280 for ; Wed, 7 May 2014 11:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd56KZXI1L_B for ; Wed, 7 May 2014 11:16:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2E25D1A0268 for ; Wed, 7 May 2014 11:16:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 65AEE2AA9FF; Wed, 7 May 2014 18:16:51 +0000 (UTC) Date: Wed, 7 May 2014 18:16:51 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507181651.GX27883@mournblade.imrryr.org> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536A6F8C.7020702@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5flv36H7dtq95CTpGnxB8O_TiOc Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:16:59 -0000 On Wed, May 07, 2014 at 06:38:20PM +0100, Alyssa Rowan wrote: > With the greatest respect, I'm simply not clear on why those uses are > best addressed that way. > > For opportunistic encryption, at least with self-signed cert usage we > can then softly migrate from opportunistic to DANE-EE pinning - and > indeed that is the route SMTP has already taken, as Viktor's helpfully > highlighted. > > Meanwhile aDH denies us that option, and broadcasts our MITM > susceptibility to Mallory. A Postfix SMTP server, whether it has TLSA RRs or not, almost always has a certificate (for interoperability reasons), often self-signed. Even though the server has a certificate, it still enables ADH and AECDH cipher-suites. Clients that don't authenticate the server negotiate ADH or AECDH cipher-suites. If the server happens to publish TLSA RRs, some *clients* will omit ADH and AECDH from their cipherlist because they are going to authenticate the server's certificate. -- Viktor. From nobody Wed May 7 11:47:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0496D1A0268 for ; Wed, 7 May 2014 11:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lValQDETKf18 for ; Wed, 7 May 2014 11:47:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB41A01D7 for ; Wed, 7 May 2014 11:47:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3CBF22AA9FF; Wed, 7 May 2014 18:47:48 +0000 (UTC) Date: Wed, 7 May 2014 18:47:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507184748.GY27883@mournblade.imrryr.org> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536A7AAE.9030801@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C-wGDmPppdGH_iiuxsxIHbTGzj0 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:47:55 -0000 On Wed, May 07, 2014 at 07:25:50PM +0100, Alyssa Rowan wrote: > > Even though the server has a certificate, it still enables ADH and > > AECDH cipher-suites. Clients that don't authenticate the server > > negotiate ADH or AECDH cipher-suites. If the server happens to > > publish TLSA RRs, some *clients* will omit ADH and AECDH from > > their cipherlist because they are going to authenticate the > > server's certificate. > > ...and my point is, Mallory can trivially spot the difference and > knows it can MITM those clients with impunity. That's more dangerous > for perpass: specifically, ubiquitous surveillance of mail text and > metadata via GCHQ's project TEMPORA. This is not a compelling reason to remove protocol capabilities. I am against banning power tools. Build them as safely as possible at reasonable cost. Both NULL and ADH/AECDH ciphersuites have real use-cases. - NULL ciphers should never be offered in combination with non-NULL ciphers. - ADH/AECDH ciphers are building blocks for using TLS with channel- binding to implement non-X.509 authentication systems. They also reduce server work-factor and handshake bloat when opportunistic clients don't check certificates. Cipher-suite signalling is just one of many ways that Mallory can determine which clients she can attack undetected. -- Viktor. From nobody Wed May 7 12:04:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818E1A0362 for ; Wed, 7 May 2014 12:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiFvOyJo3dlb for ; Wed, 7 May 2014 12:04:16 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09F1A0298 for ; Wed, 7 May 2014 12:04:16 -0700 (PDT) Message-ID: <536A83A2.3070701@akr.io> Date: Wed, 07 May 2014 20:04:02 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> In-Reply-To: <20140507184748.GY27883@mournblade.imrryr.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ryE1Vn7feJwrCzs1LMv-2dcuyVQ Subject: Re: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:04:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/05/2014 19:47, Viktor Dukhovni wrote: > This is not a compelling reason to remove protocol capabilities. I think that they are insecure _is_ a compelling reason: we seem simply to disagree on that point. More interestingly: > Cipher-suite signalling is just one of many ways that Mallory can > determine which clients she can attack undetected. I wonder, what other ways are there; and how can we stop them, too? - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaoOiAAoJEOyEjtkWi2t62/oQAJxVClVxEEZI5xLczaN5pDEN aXZXRwQeXxjA00up/5brurTweXhVvocg43XprsMHf9S/zw+V3TgeaqSejKWjduZR nIS1cRXfxdhaOWrnEHFeZcPRNGUFLzgq5nlt4/jRWsl475XCExdcSfbuFGgG27mr BKLWcxc+N0W3ZNLdz8LRJk1y+NRd9vNGHW9j2i+pYOo2eBYS91dADlS/YavnDQOz P6SQv/OPEfYWscaejWiC/1dgMx2OplSMzk5vAuNmnoRTJyMSoakUBDqYdxH1UxQ1 cOWjGiIE+bTAfe0rUQ7xVkMiBGuwthuX3tuRH+p5Y27z2pEKk47sYZ5ExSh7BS6V 4wlEUirfgNyuULrckCiridXK7RVU33Nw/WD234+w30GDL+ExGX3qTi1/mNMlHH8C hPzkCAOjkc+HJVfAqqlrW4EQvGMLx9FdjCD2wgJ6yslTYL8AmTmOrS3AMRGLL+pu Bop8tHxa+LCf8kEOlMkBzJQ0KmeYyQaKd2CunCl45cYiyNlL1mURlKe/NrXChmKP IptNwbwIQGXQ0xz8x+0+FSs9/48NyLNtZddbtor0Od/YkzwR0YtKRCW6HDTa4ajg Z1qsBuDpsacOxj4iXYKo2vV7RGJImxQ6yIEQdsHgGeSxLW3Kgsg7fpAOwUW6F93d LI7e/RyQooysl5kJ/MTx =czh+ -----END PGP SIGNATURE----- From nobody Wed May 7 12:10:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7111A02A8 for ; Wed, 7 May 2014 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mprXkynPpHaT for ; Wed, 7 May 2014 12:10:18 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF21A0219 for ; Wed, 7 May 2014 12:10:17 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D9344739B; Wed, 7 May 2014 19:10:13 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8B43247380; Wed, 7 May 2014 19:10:13 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 8938980045; Wed, 7 May 2014 19:10:13 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 7 May 2014 15:10:13 -0400 From: "Salz, Rich" To: Alyssa Rowan , "tls@ietf.org" Date: Wed, 7 May 2014 15:10:11 -0400 Thread-Topic: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) Thread-Index: Ac9qJyaOZKitXfAbQoipB+93Cw7VyQAAEv/w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> In-Reply-To: <536A83A2.3070701@akr.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5_XMsBMzMpKuce3z0X1H23Pg3io Subject: Re: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:10:19 -0000 > I think that they are insecure _is_ a compelling reason: we seem simply t= o disagree on that point. No, I think there is disagreement as to whether or not they are insecure. C= ounter-examples include a server-initiated challenge-response (such as good= old S/Key), PGP encrypted mail over SMTP, and so on.=20 /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed May 7 12:23:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB311A08B8 for ; Wed, 7 May 2014 12:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsqqEaw1wz1H for ; Wed, 7 May 2014 12:22:58 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA181A08B2 for ; Wed, 7 May 2014 12:22:58 -0700 (PDT) Message-ID: <536A8804.8000207@akr.io> Date: Wed, 07 May 2014 20:22:44 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZECjikjCbiTCw3WdvCqKUPE3jFM Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:22:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/05/2014 20:10, Salz, Rich wrote: >> I think that they are insecure _is_ a compelling reason: we seem >> simply to disagree on that point. > No, I think there is disagreement as to whether or not they are > insecure. Because the application layer provides all its own security? Then why would it need TLS; decoration for middleboxes¹? > PGP encrypted mail over SMTP Perhaps a poor example: payload protected end-to-end by OpenPGP, but interesting cleartext metadata protected hop-by-hop by TLS. ___ 1. In all fairness, that _is_ a perfectly valid, if somewhat hacky, reason. I may have answered my own question here. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaogEAAoJEOyEjtkWi2t6D6QQAIG2/lEdsD3JQEnOtyTVvlvZ mtzygFzKgYDoNAJiTinQlP8X1Ft19IKGjgmrNqMU195x8KLEf5FL8+ltmmjU0OLn Z2RviIK+JPJXYHVh+QbzHidQAvD59aI3mYzQz9akU1YFoFnxQZgXs+O/4VvywnlI sx3SflSYQH5T/LOKKK/EJ5cfXCcNKQba0eUzZHz0cKSEguiaYQL7uN2tBCuJqFKo MgBVuEbTZ3B9otXfoxyKJ/quobY9847mP00wGsjbtcaBNad320qJkPQ/T0WELLiy 7uXAP0ipSZEBZCyXsxhiTH++bMoiiztgCTvKW9ZAlxU1Jy9o0HiDCLPTIaItc2Ii A9LhfkJDy0fU8oMwixmYIvppVYjYEfM5vVYnkVbvfOZQmn4XG18QxTR8HNZ1mUoy MY0asibwtRvQu3MRZdMOl0tpgXUNM+S5O79I55KxbTDccL4+gaC0HrkEuP+VcbFy uTbcV4JnGHtSd1fFqvB3L5vs6UoOVkOAgO1b0IGSWIE9F8HjEMXCrENfzVg8oakP y7kKX3A3ZaW7wuWVH3ujOzIu6o+XwV3IAn0IVuXMe/W6abIxCT/FIa4ZLdKcdpXV V0+mpNLsVQwwciGFQ3grvOvyV/u1GAa4pyMoXIYIUqjHhL7LQnClDkuySWD8Wza6 VaIpodgY6/5n/qL68p+d =fjdi -----END PGP SIGNATURE----- From nobody Wed May 7 12:24:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F53B1A089A for ; Wed, 7 May 2014 12:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ52dTej7Nfa for ; Wed, 7 May 2014 12:24:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4521A08B6 for ; Wed, 7 May 2014 12:24:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 545FE2AA9FF; Wed, 7 May 2014 19:24:28 +0000 (UTC) Date: Wed, 7 May 2014 19:24:28 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140507192428.GB27883@mournblade.imrryr.org> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536A83A2.3070701@akr.io> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1fY8hghlyAgCDIPKlSEbiN1yaDs Subject: Re: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:24:36 -0000 On Wed, May 07, 2014 at 08:04:02PM +0100, Alyssa Rowan wrote: > > This is not a compelling reason to remove protocol capabilities. > > I think that they are insecure _is_ a compelling reason: we seem > simply to disagree on that point. There is no such thing as "secure" or "insecure" without context. Opportunistic TLS offers protection against passive attacks that cleartext does not. It makes no promises about active attacks. > > Cipher-suite signalling is just one of many ways that Mallory can > > determine which clients she can attack undetected. > > I wonder, what other ways are there; and how can we stop them, too? You can't, these attacks are above the TLS layer. It is not difficult for active attackers to downgrade opportunistic TLS to cleartext. What we can do, is promote the adoption of approaches like opportunistic DANE TLS, which adds peer-by-peer MiTM protection to an opportunistic security model. If widely implemented, this may lead to broad MiTM protection by default, but we're very early in the adoption curve. I know of only 25 domains with DANE TLSA records for SMTP. -- Viktor. From nobody Wed May 7 13:24:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E231A0372 for ; Wed, 7 May 2014 13:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTJj1dZH1beK for ; Wed, 7 May 2014 13:24:14 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA9D1A038E for ; Wed, 7 May 2014 13:24:14 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 4471C6B007F for ; Wed, 7 May 2014 13:24:10 -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:content-transfer-encoding; s= cryptonector.com; bh=533z9wuTdjDyGz9fSzRjH/5VOJE=; b=Glqc5ceIDbe INt19FKQcweKTc5nXy7OumpNBJVqtOj1/qyWcYGZsWIr6MXiXvw4ilaGjtEI5AWW jul0CJV2OI9xcZ2Gy2a9Sbo7wqYJnZWig10BiyL8ste5EcTMh0n4q3MiwDnOWfOJ Kgi13GMSaPBCo3uKfYw4RLdSDjD0/uXg= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id EC1D76B007C for ; Wed, 7 May 2014 13:24:09 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so1575959wgh.32 for ; Wed, 07 May 2014 13:24:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.10 with SMTP id d10mr524431wiz.0.1399494248719; Wed, 07 May 2014 13:24:08 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 13:24:08 -0700 (PDT) In-Reply-To: <536A8804.8000207@akr.io> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 15:24:08 -0500 Message-ID: From: Nico Williams To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vWqJUG-ZYhQDJ-gSPU6a-cbB1W0 Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:24:15 -0000 On Wed, May 7, 2014 at 2:22 PM, Alyssa Rowan wrote: > On 07/05/2014 20:10, Salz, Rich wrote: >>> I think that they are insecure _is_ a compelling reason: we seem >>> simply to disagree on that point. >> No, I think there is disagreement as to whether or not they are >> insecure. > > Because the application layer provides all its own security? It provides its own authentication, but not its own security layer. > Then why would it need TLS; decoration for middleboxes=C2=B9? Because it's simpler this way. SASL used to provide a "security layer". It's now deprecated because it only led to problems: a) double encryption in some cases (since SASL apps generally also use TLS) b) extra code in the application and the SASL mechanism, all variously duplicating TLS functionality, not always well done. With channel binding both of those go away. Nico -- From nobody Wed May 7 15:07:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787611A0400 for ; Wed, 7 May 2014 15:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwXAIp_OVVAD for ; Wed, 7 May 2014 15:07:51 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C2FE61A03FE for ; Wed, 7 May 2014 15:07:51 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id AC7E0584064 for ; Wed, 7 May 2014 15:07:47 -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=M8kXT2ckp7usp2mY68cH j2V6+z4=; b=w9yi9LSoLkQ/1bMYqkpDG/i44FJ0ZI6kTR9K5dTd01+CjBNddv7Y 9f6HUIk4HeqQZA7AX54YVOiSOUTpjsxUye3704b3YeG5aJvCw7PL7x6C0OJUubvt PLpD38cf36Z4/UF4/jpM6VtEnDTzMIapm+dzzwjH2EmouVzxHxtYvn0= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 61014584056 for ; Wed, 7 May 2014 15:07:47 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id r20so6573273wiv.1 for ; Wed, 07 May 2014 15:07:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.71.164 with SMTP id w4mr40944742wju.0.1399500466373; Wed, 07 May 2014 15:07:46 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 15:07:46 -0700 (PDT) In-Reply-To: <536A83A2.3070701@akr.io> References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> Date: Wed, 7 May 2014 17:07:46 -0500 Message-ID: From: Nico Williams To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TGUA16gV1M8NYUBoCPAdFf77kkc Cc: "tls@ietf.org" Subject: Re: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:07:52 -0000 On Wed, May 7, 2014 at 2:04 PM, Alyssa Rowan wrote: > On 07/05/2014 19:47, Viktor Dukhovni wrote: > >> This is not a compelling reason to remove protocol capabilities. > > I think that they are insecure _is_ a compelling reason: we seem > simply to disagree on that point. I disagree with your characterization. > More interestingly: > >> Cipher-suite signalling is just one of many ways that Mallory can >> determine which clients she can attack undetected. No. Mallory can only see that anon ciphersuites where offered. Mallory cannot conclude from this that anon ciphersuites will be accepted (the peer might disconnect if an anon ciphersuite is negotiated) nor can Mallory conclude that channel binding (or renengo) won't be used in that session. It's always a risk for Mallory to attempt an MITM attack. Nico -- From nobody Wed May 7 15:34:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74DE1A0416 for ; Wed, 7 May 2014 15:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7QFVLid95Yn for ; Wed, 7 May 2014 15:34:00 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCA1A041C for ; Wed, 7 May 2014 15:34:00 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so1554682yha.24 for ; Wed, 07 May 2014 15:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zctx/OPRoMsK3MswdM2FLRHhRWsrrd+PYkwDm3+ezkM=; b=Uh7nNGvhaGETbKX9TisJeDwkJF6ONphiMn/l09zZXE8SNqdkDRpdU8rLQZ937ZrlOv CM8LpJJRwUASsYVHalILmOTsJi4cfR0X2ttp9Z88EJiXoBADUSYJL/pBtt1+z9I4l93L 0vQ5A300q1tLmI2MW7gJZD0Nffp9IGKGh09sJhyrUMzsHA8LvMmxOenEbZxxxuEiHDr2 GcLoR9MHuYum7VETM4UCNip6wt4oq0En4Jf2XF4KbYKn4Q/6UP3nHPf3ZcL+aiQywdAh yuDeHshnXKyXcL/SLHDgRuNQpRwT3PNDqfe5eQ77DOoJy7j0PxDQjJybeTQBaYFn0ZKU o1EA== MIME-Version: 1.0 X-Received: by 10.236.46.225 with SMTP id r61mr34429694yhb.107.1399502036206; Wed, 07 May 2014 15:33:56 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 7 May 2014 15:33:56 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 15:33:56 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o0Hqhj457ejgg5S7tUyaCzCRpRI Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:34:01 -0000 On Wed, May 7, 2014 at 1:24 PM, Nico Williams wrote= : > On Wed, May 7, 2014 at 2:22 PM, Alyssa Rowan wrote: >> On 07/05/2014 20:10, Salz, Rich wrote: >>>> I think that they are insecure _is_ a compelling reason: we seem >>>> simply to disagree on that point. >>> No, I think there is disagreement as to whether or not they are >>> insecure. >> >> Because the application layer provides all its own security? > > It provides its own authentication, but not its own security layer. > >> Then why would it need TLS; decoration for middleboxes=C2=B9? > > Because it's simpler this way. > > SASL used to provide a "security layer". It's now deprecated because > it only led to problems: > > a) double encryption in some cases (since SASL apps generally also use TL= S) > b) extra code in the application and the SASL mechanism, all variously > duplicating TLS functionality, not always well done. > > With channel binding both of those go away. But you get a new issue: channel binding doesn't work with all ciphersuites because of the DHE validation issue. I think SASL is important enough to support anonymous ECDH, and maybe anonymous DH if we can fix it. However, using it without authenticating endpoints isn't getting anything. Sincerely, Watson Ladd > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed May 7 15:42:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3713D1A0429 for ; Wed, 7 May 2014 15:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwtVhTw1389z for ; Wed, 7 May 2014 15:42:13 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF881A0427 for ; Wed, 7 May 2014 15:42:13 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 704372006D30D for ; Wed, 7 May 2014 15:42:09 -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=h9gFUDQEROvAL0TuP/0V NgzSAr8=; b=xTn63D8t/1RVGkS8TtK17iPkTvIqbDsUuyvANKf5Xw+MpH+5LKDi fHjaa39/vUn22jtK/AudekJPKBYHB+5qw+GmVz6CXu39lJHw8KFxAxfUu2RxjLgK sh9F31PnS03Yq7VEcmu/ThB0IAkOEaB3WVIfFeA5pgfnhrqr2aTMmv8= Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 5A7E52006D30C for ; Wed, 7 May 2014 15:42:09 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wo20so2037295obc.7 for ; Wed, 07 May 2014 15:42:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.250.200 with SMTP id ze8mr6287375obc.72.1399502527963; Wed, 07 May 2014 15:42:07 -0700 (PDT) Received: by 10.182.127.50 with HTTP; Wed, 7 May 2014 15:42:07 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 17:42:07 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J9pKWhMcVokWa-Cy9xBjfu6Hpzo Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:42:14 -0000 On Wed, May 7, 2014 at 5:33 PM, Watson Ladd wrote: > But you get a new issue: channel binding doesn't work with all > ciphersuites because of the DHE validation issue. I think SASL is Can you be more specific? What DHE validation issue? > important enough to support anonymous ECDH, and maybe anonymous DH if > we can fix it. However, using it without authenticating endpoints > isn't getting anything. Please explain in detail. Channel binding involves authentication of entities at the application layer -- authentication is done there, so why must it be done by TLS? Nico -- From nobody Wed May 7 16:10:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0691A0439 for ; Wed, 7 May 2014 16:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDKJcC_JPQzX for ; Wed, 7 May 2014 16:10:16 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E9B551A0434 for ; Wed, 7 May 2014 16:10:15 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 9so1467991ykp.19 for ; Wed, 07 May 2014 16:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y1E+OKFYO8O+mxOc+cslsGtlzHH0ZU7V98Z0Qz+a44g=; b=MRaKQBWrlXrKHhaXqBE6xjF2o3Nv1CTlO3XICT7jMhku0wb+Yo5YjZFSO3D+8YAozd o+IHNTnnWvV8sOdNoIsd9VvZ0YHy+CQ3qQij6Zk0xM6DGAtV2TWDZeoWmZPjZ4mnruau svEYM1JTJDGzdZFFTByrxFwzrQGQs3ZabpSVTcWo6FC10rsvcF6ycmD+Ww3N7F1qsCRV gEV6T9Aq0Y7xUA3/Me1TOynr1xwzIOqDBvpZNWBhJYC/YDQpxkp8a439IOw+HE3SuAc9 vQXYlYy+nve9rzHwMvaXUhVjEsXSemVhRFHbQL3SeF9MG85Ajuv6CgOV0f1zOyOFd37c pdgw== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr70284533yhn.87.1399504211618; Wed, 07 May 2014 16:10:11 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 7 May 2014 16:10:11 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 16:10:11 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IGMwyH2LtcrkLRgIw6BW3KUqV6Y Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:10:18 -0000 On Wed, May 7, 2014 at 3:42 PM, Nico Williams wrote: > On Wed, May 7, 2014 at 5:33 PM, Watson Ladd wrote: >> But you get a new issue: channel binding doesn't work with all >> ciphersuites because of the DHE validation issue. I think SASL is > > Can you be more specific? What DHE validation issue? Currently DHE groups aren't validated. As a result it is possible for the server to force the premaster secret to be just about anything. This breaks the tls-unique channel binding after resumption. >> important enough to support anonymous ECDH, and maybe anonymous DH if >> we can fix it. However, using it without authenticating endpoints >> isn't getting anything. > > Please explain in detail. Channel binding involves authentication of > entities at the application layer -- authentication is done there, so > why must it be done by TLS? Sorry, "it" was referring to anonymous DH. Sincerely, Watson Ladd > > Nico > -- From nobody Wed May 7 16:13:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C0A1A0427 for ; Wed, 7 May 2014 16:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGB2KKTnjkpg for ; Wed, 7 May 2014 16:12:45 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 125141A03F4 for ; Wed, 7 May 2014 16:12:45 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 9so1472393ykp.13 for ; Wed, 07 May 2014 16:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Owm5h9FXccj9YsbtcbojggsnXl+tZkKwy0PxWQIMo6g=; b=Hxv8lhxIHukU2kysZzXl1xpJrUk8F+puwo8l4QzhYrK0Yyas6sGQQMtxqUWB3y3ZK3 /Jj/U7FeuD35iK9M9p0ipgj1ElA9w1KE4sC24EcYJpS+UmuoDpP32BTRdnel+AsXmwcv ISLCFTXdfM8yxflzxftUo4DMv0S4O5ECRtiktvNQkvJS0ckUFEr729QCt4op8zxKsEwa vCZNSfsa8wt8Y8ncWqqr4SDqWXN0xZC5VUquxBMR1hnCtsrlWbPEXvMuzn9N/Y7/yvHq J4CGQWBLjHE8L766TtBzt7ZYnFBX8P8Kp+Ucg1Mu8U9n3fVmoBp2q+Aawbhk9MQyJchE RUSA== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr153297yhi.4.1399504360775; Wed, 07 May 2014 16:12:40 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 7 May 2014 16:12:40 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> Date: Wed, 7 May 2014 16:12:40 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BCh4OU1FDQXzLf4TjSvicOWTdRk Cc: "tls@ietf.org" Subject: Re: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:12:46 -0000 On Wed, May 7, 2014 at 3:07 PM, Nico Williams wrote: > On Wed, May 7, 2014 at 2:04 PM, Alyssa Rowan wrote: >> On 07/05/2014 19:47, Viktor Dukhovni wrote: >> >>> This is not a compelling reason to remove protocol capabilities. >> >> I think that they are insecure _is_ a compelling reason: we seem >> simply to disagree on that point. > > I disagree with your characterization. > >> More interestingly: >> >>> Cipher-suite signalling is just one of many ways that Mallory can >>> determine which clients she can attack undetected. > > No. Mallory can only see that anon ciphersuites where offered. > Mallory cannot conclude from this that anon ciphersuites will be > accepted (the peer might disconnect if an anon ciphersuite is > negotiated) nor can Mallory conclude that channel binding (or renengo) > won't be used in that session. It's always a risk for Mallory to > attempt an MITM attack. So they do the MITM, see that SASL is being used, the connection breaks, and then what? Or they do the MITM, the peer disconnects because they didn't really mean it anyway, and then what? Sincerely, Watson Ladd > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed May 7 16:14:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6691A042A for ; Wed, 7 May 2014 16:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NORapJcfEibR for ; Wed, 7 May 2014 16:14:06 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB751A0432 for ; Wed, 7 May 2014 16:14:06 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 3C12959805F for ; Wed, 7 May 2014 16:14:02 -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=FrGrGkwfZ5LOkd6YhpfC 39JlpcU=; b=G5j+jLFKI4eSE96CyeS2DAx2axu8wLPcGoS+op4D3tHQHlv8fXdX OYgQedj0Khv05RRDP75z/lovs/3oi7hK1uH0evn3oJqqekVtFPBrAhvHp8ComB7j dbKhVgMtU8PdjKgfQ1nqf0dW5afAMEyofwRo5Qh5U2BzFTF/fjdODtE= Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 2464D598057 for ; Wed, 7 May 2014 16:14:02 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id vb8so2098024obc.14 for ; Wed, 07 May 2014 16:14:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.55.97 with SMTP id r1mr9839oep.5.1399504441768; Wed, 07 May 2014 16:14:01 -0700 (PDT) Received: by 10.182.127.50 with HTTP; Wed, 7 May 2014 16:14:01 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 18:14:01 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mdKnmyG3ChWpcsVfgjPDQLBtx8s Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:14:07 -0000 On Wed, May 7, 2014 at 6:10 PM, Watson Ladd wrote: > On Wed, May 7, 2014 at 3:42 PM, Nico Williams wrote: >> On Wed, May 7, 2014 at 5:33 PM, Watson Ladd wrote: >>> But you get a new issue: channel binding doesn't work with all >>> ciphersuites because of the DHE validation issue. I think SASL is >> >> Can you be more specific? What DHE validation issue? > > Currently DHE groups aren't validated. As a result it is possible for > the server to force the premaster secret to be just about anything. > This breaks the tls-unique channel binding after resumption. It would have been easier if you're referred to this as the resumption bug. I'm assuming this will get fixed. Are you assuming it won't? Please explain. Nico -- From nobody Wed May 7 16:16:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041E31A0433 for ; Wed, 7 May 2014 16:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OLUxRZ_Q1rV for ; Wed, 7 May 2014 16:16:03 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 383CA1A03F4 for ; Wed, 7 May 2014 16:16:03 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1FB9E20202C for ; Wed, 7 May 2014 16:15:59 -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=BHgzhXuk27sgv4ElWoH5 Tlw2pH4=; b=p+2kovpqEO2mG1/5dYu1r79L/tYvIYdunIjhyK8JWvr9p5OictX4 BaIC+PkfGdxyqKts5TsFHJhJeFGDCz+MyPgSw/4J8qpwcO1iq25FpZySSKV9kKGx r7/GnZoA8i+tCrBB/ecFPvVWYYJ5vlzICfOLDlN2RUX5MFDHy1lolhQ= Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 00FAB202018 for ; Wed, 7 May 2014 16:15:58 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so2091656oag.26 for ; Wed, 07 May 2014 16:15:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.55.97 with SMTP id r1mr16237oep.5.1399504558649; Wed, 07 May 2014 16:15:58 -0700 (PDT) Received: by 10.182.127.50 with HTTP; Wed, 7 May 2014 16:15:58 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> Date: Wed, 7 May 2014 18:15:58 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iIWyWdo2f69AB1sJQqpTLRUwr1M Cc: "tls@ietf.org" Subject: Re: [TLS] Fingerprinting weaknesses (was: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:16:04 -0000 On Wed, May 7, 2014 at 6:12 PM, Watson Ladd wrote: > On Wed, May 7, 2014 at 3:07 PM, Nico Williams wrote: >> On Wed, May 7, 2014 at 2:04 PM, Alyssa Rowan wrote: >>>> Cipher-suite signalling is just one of many ways that Mallory can >>>> determine which clients she can attack undetected. >> >> No. Mallory can only see that anon ciphersuites where offered. >> Mallory cannot conclude from this that anon ciphersuites will be >> accepted (the peer might disconnect if an anon ciphersuite is >> negotiated) nor can Mallory conclude that channel binding (or renengo) >> won't be used in that session. It's always a risk for Mallory to >> attempt an MITM attack. > > So they do the MITM, see that SASL is being used, the connection > breaks, and then what? And then the user only observes the re-connect or the failure. Either way the user did not fall to an MITM attack. > Or they do the MITM, the peer disconnects because they didn't really > mean it anyway, and then what? The user doesn't get MITMed. Alternative the client was trying to get opportunistic security, and speaking to an MITM is better than sending cleartext (which would have been the alternative). Nico -- From nobody Wed May 7 16:40:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A4E1A0435 for ; Wed, 7 May 2014 16:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsQTvOOz6pja for ; Wed, 7 May 2014 16:39:58 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id CF8941A042A for ; Wed, 7 May 2014 16:39:57 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 200so1529805ykr.0 for ; Wed, 07 May 2014 16:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d/ucKv++fOE88LPv5i+XfUr7uQY9ET52bWL4Xr8aRsM=; b=Q/0igXxsGFppmiqAwsqpAbOxgKQK2uXqkMU/Fak0CR4z073IFTcH7pdxw05lDsOsmn Tpg4sJNPvw/zREqDK8ItfVDjyk+e18G/9NyxvB7vLrVRKJw46e/uKCU4W6rOOYR2rJHP BAyhtM/Ga//8gtLD8U7rBVg/+YIl77+SQCl2w79Wsmrn/iU3RfKe6/GaJ6Vhfo9XyghP 2qwJupTcTGezl0j2MHl3MD/Ri1P4tU7bM9FSPg2o8GEaC22brd4W+RC8IErSYnqC1LJb s5k91dGLithk3JsmtKgDezMyyyzVzFmA9kBt7zYLKdWMrhYVT7IMcMqbGNYPdpYlm+2S qPnQ== MIME-Version: 1.0 X-Received: by 10.236.125.12 with SMTP id y12mr269333yhh.42.1399505993417; Wed, 07 May 2014 16:39:53 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 7 May 2014 16:39:53 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 16:39:53 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jj7g8T6q-tTt6vEtflgNc3vcJ-U Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:39:59 -0000 On Wed, May 7, 2014 at 4:14 PM, Nico Williams wrote: > On Wed, May 7, 2014 at 6:10 PM, Watson Ladd wrote: >> On Wed, May 7, 2014 at 3:42 PM, Nico Williams wrote: >>> On Wed, May 7, 2014 at 5:33 PM, Watson Ladd wrote: >>>> But you get a new issue: channel binding doesn't work with all >>>> ciphersuites because of the DHE validation issue. I think SASL is >>> >>> Can you be more specific? What DHE validation issue? >> >> Currently DHE groups aren't validated. As a result it is possible for >> the server to force the premaster secret to be just about anything. >> This breaks the tls-unique channel binding after resumption. > > It would have been easier if you're referred to this as the resumption bug. > > I'm assuming this will get fixed. Are you assuming it won't? Please explain. If it gets fixed anonymous DH will work just fine for channel binding: the premaster secret will always be unique. Sincerely, Watson Ladd > > Nico > -- -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed May 7 16:42:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838131A043F for ; Wed, 7 May 2014 16:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7bOmL93vlci for ; Wed, 7 May 2014 16:42:25 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 64A391A042A for ; Wed, 7 May 2014 16:42:25 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 475F21DE059 for ; Wed, 7 May 2014 16:42:21 -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=pqyliBSthlYaW36PIKW/ eoB5Ot4=; b=iHSh8KDmyzcTlrEybLEVIvEHzsJgOM4k5tTMvs3Bb60GX5ujv/k/ YF2pAfjPEm6k0RQb43HrcENJelNATpRowwz/brmabkPcLlakcvN7T7dORg4d2aaA 0nEs5L9NPUipz+ZUgBTxXbO/Ur+HwOmhx4nLKLx6GNxoBVKoLeJu+cA= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id EF7AC1DE058 for ; Wed, 7 May 2014 16:42:20 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so7218767wiw.9 for ; Wed, 07 May 2014 16:42:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.216.68 with SMTP id oo4mr29440wjc.69.1399506139800; Wed, 07 May 2014 16:42:19 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 16:42:19 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 18:42:19 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h-sQTMSldk0yRaRhAaXo1-q6w4M Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:42:26 -0000 On Wed, May 7, 2014 at 6:39 PM, Watson Ladd wrote: > On Wed, May 7, 2014 at 4:14 PM, Nico Williams wrote: >> I'm assuming this will get fixed. Are you assuming it won't? Please explain. > > If it gets fixed anonymous DH will work just fine for channel binding: > the premaster secret will always be unique. Clearly. No one disagrees with that. You're making statements that implicitly assume it's not fixed, so I want to know if you're assuming it won't be fixed. Also, really, this is an ancillary issue being dealt with in a separate thread. It's NOT germane to your proposal to remove features that the rest of us don't want removed. Please address the arguments against removal. Nico -- From nobody Wed May 7 16:48:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF701A043F for ; Wed, 7 May 2014 16:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tWFV0dOCQHt for ; Wed, 7 May 2014 16:48:07 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9F1A042A for ; Wed, 7 May 2014 16:48:07 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id z6so1248598yhz.39 for ; Wed, 07 May 2014 16:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qt/G2mguD/FdF0Gd2UwLtsVbjoojBv+GrAH7TkvPSIE=; b=LN0ICU8dWRMt5qedJKLULX6aajuJi/uy7GDc9nrboGalfswtVmNkyIgoZL+/AG/Sw1 Q5QwC3PFKI0NRnGkXIIVluI1XBRKDSOwQniWkcylZ17ArwaCwZKDkhddeo+06LBGFu08 x5ewhgrT5ylcoGqTFtQvM5E/8U3Kccy9LSZdF6kGp2H6t2on5AzIuCVdAdFXcJh1MoHa v/wwGs1vuissrp7UwPgZ/aYzkjSKUo3C45v0mCrV3xd5W8DaIeVkt/p5X7m+OjvH8xQA EP3WddVbOUANlIKeLa20CzGHIVY+35FpSvy2yT3cii1igAvCnTUpt4qcreazUXKVbPI7 ezTA== MIME-Version: 1.0 X-Received: by 10.236.90.12 with SMTP id d12mr232038yhf.120.1399506482904; Wed, 07 May 2014 16:48:02 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 7 May 2014 16:48:02 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 16:48:02 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eQcOZdUGfNbOaT2hvwug7AzcXvE Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:48:13 -0000 On Wed, May 7, 2014 at 4:42 PM, Nico Williams wrote: > On Wed, May 7, 2014 at 6:39 PM, Watson Ladd wrote: >> On Wed, May 7, 2014 at 4:14 PM, Nico Williams wrote: >>> I'm assuming this will get fixed. Are you assuming it won't? Please explain. >> >> If it gets fixed anonymous DH will work just fine for channel binding: >> the premaster secret will always be unique. > > Clearly. No one disagrees with that. You're making statements that > implicitly assume it's not fixed, so I want to know if you're assuming > it won't be fixed. > > Also, really, this is an ancillary issue being dealt with in a > separate thread. It's NOT germane to your proposal to remove features > that the rest of us don't want removed. Please address the arguments > against removal. I changed my mind about anonymous DH: it's useful enough in SASL to keep. You replied to a message that had this sentence in it. I think the null encryption cipher should definitely stay out: the only use I've heard of is extremely niche, namely large datasets with slow CPUs on both ends. SIncerely, Watson Ladd > > Nico > -- -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed May 7 17:01:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59E1A043F for ; Wed, 7 May 2014 17:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYr88QRrTX8H for ; Wed, 7 May 2014 17:01:06 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8E54E1A01B3 for ; Wed, 7 May 2014 17:01:06 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 5299E20052935 for ; Wed, 7 May 2014 17:01:02 -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=c45iyP6qOBAHFvdX0v/L 1QAr8v0=; b=Fm2gQTpjVjOkJ2s2e2Z/HHjcz8F3Ji8YOjw/RJsvz27vKb15r5mK ELpScADnT6a325BsVWqBwdLcZwM1DGH12ESDSpmNbogRFEWIz6TCfigPnmMP+0Ps DbFRg72KirPtmFkhOMntqM9Q+HATo3s7JcmuKikudD8oUSk+FS08qF4= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 0804A2005D807 for ; Wed, 7 May 2014 17:01:01 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so1715539wes.7 for ; Wed, 07 May 2014 17:01:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.216.68 with SMTP id oo4mr72747wjc.69.1399507260932; Wed, 07 May 2014 17:01:00 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 17:01:00 -0700 (PDT) In-Reply-To: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <20140507181651.GX27883@mournblade.imrryr.org> <536A7AAE.9030801@akr.io> <20140507184748.GY27883@mournblade.imrryr.org> <536A83A2.3070701@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> Date: Wed, 7 May 2014 19:01:00 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y4i0F2Bb4ELhx347E8e3XevxVbI Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:01:07 -0000 On Wed, May 7, 2014 at 6:48 PM, Watson Ladd wrote: >>> If it gets fixed anonymous DH will work just fine for channel binding: >>> the premaster secret will always be unique. >> >> Clearly. No one disagrees with that. You're making statements that >> implicitly assume it's not fixed, so I want to know if you're assuming >> it won't be fixed. >> >> Also, really, this is an ancillary issue being dealt with in a >> separate thread. It's NOT germane to your proposal to remove features >> that the rest of us don't want removed. Please address the arguments >> against removal. > > I changed my mind about anonymous DH: it's useful enough in SASL to Good. That's a relief. You and I both can change our minds about such things. > keep. You replied to a message that had this sentence in it. "If it gets fixed anonymous DH will work just fine for channel binding: ..." -- I didn't take that to mean that you'd changed your mind, only that you were explaining something [that I already knew]. > I think the null encryption cipher should definitely stay out: the > only use I've heard of is extremely niche, namely large datasets with > slow CPUs on both ends. I have no opinion yet as to null encryption ciphersuites. In general I think they are best left out, but I should hear more about their uses before agreeing to remove them. Nico -- From nobody Wed May 7 17:15:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58031A044C for ; Wed, 7 May 2014 17:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chduN-qtoZ5W for ; Wed, 7 May 2014 17:15:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E334F1A044A for ; Wed, 7 May 2014 17:15:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 76E6D2AB0B4; Thu, 8 May 2014 00:15:32 +0000 (UTC) Date: Thu, 8 May 2014 00:15:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140508001532.GG27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vhns5ydHGtyaR6O0j1T5u3GEKAw Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:15:40 -0000 On Wed, May 07, 2014 at 04:48:02PM -0700, Watson Ladd wrote: > I think the null encryption cipher should definitely stay out: the > only use I've heard of is extremely niche, namely large datasets with > slow CPUs on both ends. Any bulk transfer application that wants to work at wire rates to move already encrypted data with authentication of the endpoints. The solution to avoid accidental use of NULL ciphers is in the client API, no client HELLO should ever include a mixture of NULL and non-NULL ciphers-suites. The "let's remove everything that I personally don't use" crusade seems rather heavy-handed. Successful general-purpose protocols have more knobs than niche protocols. That's the cost of success. -- Viktor. From nobody Wed May 7 17:59:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40B41A0425 for ; Wed, 7 May 2014 17:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JNleFD7GroX for ; Wed, 7 May 2014 17:58:47 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9231A0069 for ; Wed, 7 May 2014 17:58:47 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id q9so1567162ykb.35 for ; Wed, 07 May 2014 17:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0BIT6fndOk+lL9nV6LZQKk9Bl62FwjNCaIlBNqiNh7A=; b=UH6YLJV5Xnllz4et1zTGKAD40Bcg59JlJLTWldTGvAC8qFR2lcUAe9RvuyUc0samhd ZvoJatCBAViFT2Tb1h6VvnWQIR7iImhmPT4kc5hkX/dND4YOQ64/TtPqD5ludcOTFRQ5 BAwdUmkuaI0My0Mursoy87aMcFd7tadBTJm32wOuQTyVvpXrY/FUHcyI7pK9lERCLTIQ 5Ib7CIEC59F7eqA9KzO72aZFfbNZ+MBNNhJoqzkxs+Mm6Rxqrr+Q9emOKda4nNSSHYxh oKW/9SMyXq0mqHKg2DMI3WHZROMlw5+uGsBMmcsaaVeT27djUUTw4p+ZWXj1ek4IMQKy GDCA== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr451676yhj.63.1399510723120; Wed, 07 May 2014 17:58:43 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 7 May 2014 17:58:43 -0700 (PDT) In-Reply-To: <20140508001532.GG27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> <20140508001532.GG27883@mournblade.imrryr.org> Date: Wed, 7 May 2014 17:58:43 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aA9iWFHYMaSfBclu1ngTGkm_X24 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:58:49 -0000 On May 7, 2014 5:15 PM, "Viktor Dukhovni" wrote: > > On Wed, May 07, 2014 at 04:48:02PM -0700, Watson Ladd wrote: > > > I think the null encryption cipher should definitely stay out: the > > only use I've heard of is extremely niche, namely large datasets with > > slow CPUs on both ends. > > Any bulk transfer application that wants to work at wire rates to > move already encrypted data with authentication of the endpoints. > > The solution to avoid accidental use of NULL ciphers is in the > client API, no client HELLO should ever include a mixture of NULL > and non-NULL ciphers-suites. Why not make that a MUST in the RFC, and the same for anonymous DH? I think this solves most of the configuration issues without making any uses impossible. To those who haven't been following along that means the following: 1: Your ciphersuite list can have either authenticated or unauthenticated ciphers, but cannot have both. 2: It can have null encryption or use encryption, but not both. 3: If you try to break the above rules, the remote side (assuming it is compliant) bails out. I can live with that: it makes accidental misconfiguration cause everything to stop working, thus preventing a quiet misconfiguration incident. > > The "let's remove everything that I personally don't use" crusade > seems rather heavy-handed. Successful general-purpose protocols > have more knobs than niche protocols. That's the cost of success. Maybe if TLS wasn't "successful" we wouldn't have had the terrible track record on security, because it would be simple enough to understand and see the problems. That's vastly preferable to having problems that will continue to bite us for years because broken versions of the protocol were widely deployed. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 7 18:07:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0378C1A0453 for ; Wed, 7 May 2014 18:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5LGCw8GTpoS for ; Wed, 7 May 2014 18:06:57 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A8F3F1A044C for ; Wed, 7 May 2014 18:06:57 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 155071655C3; Thu, 8 May 2014 01:06:53 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 0AAE91655BB; Thu, 8 May 2014 01:06:53 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id E6C489804E; Thu, 8 May 2014 01:06:52 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 7 May 2014 21:06:52 -0400 From: "Salz, Rich" To: Watson Ladd , "tls@ietf.org" Date: Wed, 7 May 2014 21:06:51 -0400 Thread-Topic: [TLS] The risk of misconfiguration Thread-Index: Ac9qWNuEtPeEkL+YT6WRf2bfutTgTAAANftg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E47E@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> <20140508001532.GG27883@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bdh62KBY0AABmQvi4eE4UOd0z3c Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 01:06:59 -0000 >> The solution to avoid accidental use of NULL ciphers is in the client=20 >> API, no client HELLO should ever include a mixture of NULL and=20 >> non-NULL ciphers-suites. > Why not make that a MUST in the RFC, and the same for anonymous DH? > I think this solves most of the configuration issues without making any u= ses impossible. I think this is worth serious consideration. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed May 7 18:23:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C811A045C for ; Wed, 7 May 2014 18:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GaHQv8SOM6L for ; Wed, 7 May 2014 18:23:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E94F21A044D for ; Wed, 7 May 2014 18:23:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 67CC32AB0B4; Thu, 8 May 2014 01:23:18 +0000 (UTC) Date: Thu, 8 May 2014 01:23:18 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140508012318.GJ27883@mournblade.imrryr.org> References: <20140508001532.GG27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V-_c9E3d5fM2xd4OsY1yWHHzro0 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 01:23:25 -0000 On Wed, May 07, 2014 at 05:58:43PM -0700, Watson Ladd wrote: > > The solution to avoid accidental use of NULL ciphers is in the > > client API, no client HELLO should ever include a mixture of NULL > > and non-NULL ciphers-suites. > > Why not make that a MUST in the RFC No objection there, the use of NULL ciphers is typically by mutual agreement between cooperating peers. They are disabled by default, and both ends have to enable them, with the client enabling *only* NULL ciphers where applicable. > And the same for anonymous DH? Sadly this does not work. Clients often don't know whether the server supports any ADH cipher-suites or not. Sending only ADH is going to result in handshake failure. > I think this solves most of the configuration issues without making any > uses impossible. Yes, for NULL ciphers. > 1: Your ciphersuite list can have either authenticated or > unauthenticated ciphers, but cannot have both. No on this one. That makes ADH/AECDH unusable. > 2: It can have null encryption or use encryption, but not both. This is what I am proposing as an implementation feature in the client API. It need not be a protocol feature. > 3: If you try to break the above rules, the remote side (assuming it > is compliant) bails out. Just rule "2", not rule "1". If you absolutely must remove something, I don't know of any plausible use-case for the following cipher-suite: $ openssl ciphers -v aNULL+eNULL AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 This just MACs each message post an authenticated key exchage. So you get all or nothing message integrity. When Postfix enables eNULL it always disables aNULL, so this cipher-suite is never turned on. I don't think there is either a good reason to continue to to support this, or a real benefit to "banning" it. -- Viktor. From nobody Wed May 7 18:34:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688EC1A045E for ; Wed, 7 May 2014 18:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 702-RMz9sXs0 for ; Wed, 7 May 2014 18:33:38 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A95F31A0455 for ; Wed, 7 May 2014 18:33:38 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 453AE508064 for ; Wed, 7 May 2014 18:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=Kd58+i59XPfI7lxVevR26XYPrRU=; b=t0zDXVyNVmO tdT6V0gs5CyDWyvLeKpYRuL/QgD/pGyeIGJEWRr0JMf5NH4HYAmRxeZcaqzc0tGy 2/Oypp6CVNcLCo5Ibg4Pdj/lZbobYx0xcgskxB6F8FtCh3gbi2T1g09DX+9w/A2j 1V+cxogO+2tqo55vGH0GfNKVFtwo/ht8= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id EE521508072 for ; Wed, 7 May 2014 18:33:33 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so1845340wes.14 for ; Wed, 07 May 2014 18:33:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr872120wic.5.1399512812779; Wed, 07 May 2014 18:33:32 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 7 May 2014 18:33:32 -0700 (PDT) Date: Wed, 7 May 2014 20:33:32 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4FP54o0LRRSAmdfYFgstKyJGKVU Cc: "tls@ietf.org" Subject: [TLS] TLS abstract API (Re: The risk of misconfiguration) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 01:33:39 -0000 On Wed, May 7, 2014 at 7:58 PM, Watson Ladd wrote: > On May 7, 2014 5:15 PM, "Viktor Dukhovni" wrote: >> The solution to avoid accidental use of NULL ciphers is in the >> client API, no client HELLO should ever include a mixture of NULL >> and non-NULL ciphers-suites. > > Why not make that a MUST in the RFC, and the same for anonymous DH? [...] No objection from me! HOWEVER, TLS is a protocol and does not come with a standard API, not even an abstract API. The most likely result will be a handful of requirements and recommendations for APIs, but nothing like an abstract API, or even a big picture. I've long been saying that lack of abstract APIs is a big problem for us. Protocols that lack APIs but would greatly benefit from having them: - IPsec (see Solaris' IP_SEC_OPT socket option) - PKIX (geez, PKIX naming is bloody painful; an API would help a lot) - TLS ('nuff said) - SASL (it has one, it's called Cyrus SASL, snark) - DNS[SEC] and many others. Not every protocol needs an API (e.g., SSHv2 doesn't, but then there are plenty of SSHv2 libraries now, so maybe it does). But TLS sure does need one. Nico -- From nobody Wed May 7 23:41:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98371A0574 for ; Wed, 7 May 2014 23:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooyvQHY6vvLe for ; Wed, 7 May 2014 23:41:09 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89C1A04DC for ; Wed, 7 May 2014 23:41:08 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so7546337wiw.15 for ; Wed, 07 May 2014 23:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SHaXX7hVihjrHWYFl4Q+v/+e8L8mj6d2oMjguuJrqt8=; b=c9CyASUcLeLDaJYvTxdAhgUkmlAeAucGvp8VhoLR/0HxfyUCA7K2jPcJU+zV3dRs4W UaOuEY2Z3I678GG6l7OTUMLcFo9W4XKmVymp3974PPRbPqE8HY+KVnl6iW2E8pvWmk6r 0i3e4LaOSOlAGX0LXgEsj68CZy1nASmqWYs3R2yRKje403/gpEBAdBXEesBUvrUedqjW OZmjPEKSKD8pZ9GlPQKBXqnxYfVrZBQLDUegQbqpPbzHz+T3Ew2aV2ih0FPa/wzH0gCU Mj4k66+wdK1Hijc6l3V/CA2t2GUb938hD9cHTKtlmdkpKhZKDmry5C5XuR7ylqK+GXE7 Ezqw== X-Received: by 10.180.11.239 with SMTP id t15mr1893033wib.25.1399531264199; Wed, 07 May 2014 23:41:04 -0700 (PDT) Received: from [172.24.249.242] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id fw13sm2103531wic.6.2014.05.07.23.41.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 23:41:03 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E47E@USMBX1.msg.corp.akamai.com> Date: Thu, 8 May 2014 09:40:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> <20140508001532.GG27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E47E@USMBX1.msg.corp.akamai.com> To: Watson Ladd X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6IvkI2W2vMy0JDCZBvcKwkmYk3Q Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 06:41:10 -0000 On May 8, 2014, at 4:06 AM, Salz, Rich wrote: >>> The solution to avoid accidental use of NULL ciphers is in the = client=20 >>> API, no client HELLO should ever include a mixture of NULL and=20 >>> non-NULL ciphers-suites. >=20 >> Why not make that a MUST in the RFC, and the same for anonymous DH? >> I think this solves most of the configuration issues without making = any uses impossible. >=20 > I think this is worth serious consideration. I agree that it=92s worth consideration, but we have to be clear on what = we=92re making a MUST here. We can mandate that clients don=92t mix NULL and non-NULL ciphersuites = in the ClientHello. In that case, if some client does send a mixture of = NULL and non-NULL, we can point to the implementers and say =93your = client is not compliant with the RFC=94. And they could reply that it=92s = possible to configure their client to comply. I don=92t know how much = that helps security, but it seems like a strange way to force something = that is basically a UI/API issue. BTW: does 40-bit export level DES go = with the NULL or the non-NULL? Don=92t answer that. That=92s just me = being facetious. The other thing we could mandate is that servers validate the = ClientHello, to make sure that it doesn=92t contain ciphersuites of both = kinds. That would actually help, because it would drive misconfigured = clients off the Internet rather than into potentially insecure modes, = but that=92s one reason server makers would resist having this change. Regarding ADH I=92m not sure. It makes sense that clients that don=92t = require server identity should not be blocked just because the server = insists on authenticating itself. OTOH you could make the same argument = for clients that don=92t require confidentiality. So I don=92t know = where I stand on this. Yoav From nobody Thu May 8 00:33:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636951A03F2 for ; Thu, 8 May 2014 00:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW7qzjDCUp-h for ; Thu, 8 May 2014 00:33:00 -0700 (PDT) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id 6D78B1A010A for ; Thu, 8 May 2014 00:33:00 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s487WeRZ015613; Thu, 8 May 2014 09:32:40 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s487Waq5015612; Thu, 8 May 2014 09:32:36 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Thu, 08 May 2014 09:32:36 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wAS5TkFM62zDHKxV3yg6nyX95z0 Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 07:33:02 -0000 I'm going back to look at the draft-nir-cfrg-chacha20-poly1305-02 draft, from an implementation point of view. One thing that I think is suboptimal is that some buffering is required between the chacha encryption and the mac. First consider the case that the ad | length(ad) is a multiple of the poly1305 blocksize (i.e., 16 bytes, and with the current draft this would happen when length(ad) mod 16 = 8). Then for authentication, the crypto text starts at a poly1305 block boundary. So each encrypted chacha block, 64 bytes, lines up nicely as 4 poly1305 blocks. For a software implementation, there's some potential for short-circuiting the conversion from integers to octets and back. For a hardware implementation, I think it would also be pretty straight-forward to do those 4 poly1305 blocks in parallel if desired. On the other hand, if cryptotext doesn't start at a poly1305 block boundary, i.e., the general case, the cryptotext has to be buffered and shifted around when split into poly1305 blocks. The above software optimizations get much more complex or impossible. And I would imagine (but I'm no hardware designer) that it adds significant complexity for a hardware implementation. Is this something you'd want to address? After all, high performance is one of the primary design goals for both chacha and poly1305. The easiest way I see is to change the formatting for authentication to ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext) where pad1 and pad2 are the minimum number of zero bytes needed to get to 16-byte boundary. The length fields fill up a poly1305 block of their own, and I think they should definitely use little-endian encoding, since that's what poly1305 uses and little-endian makes it easier to assemble the block without going via any byte representation. There are some other possibilities, taking advantage of the fact that poly1305 has an unambibuous encoding for short blocks. E.g, if the ad is the single byte "a", 0x61, zero-padding produces the poly1305 coefficient 0x10000000000000061, but one could also represent it as 0x161, as is specified for a final, short, block in poly1305-aes. With some care, I think one could even drop both length fields. What's needed is to use the poly1305 short block encoding for the final ad and crypto text blocks, and in addition make sure that the ad *always* is terminated with a short block, by adding an empty block (poly1305 coefficient 0x1) between ad and cryptotext in case the ad length is a multiple of 16. Another minor point: The unused 32 bytes of the first chacha block (after the 32 bytes used for the poly1305 subkeys), could they be considered a separate (and optional) output? When chacha-poly1305 is used in openssh, they encrypt the packet length field separately, and they seem to be using another instance of chacha for that, with an independent key. Which seems a bit unnecessary when there are plenty of left over keystream bytes from the chacha-poly1305 instance they use for the message payload. Regards, /Niels -- Niels Mller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Thu May 8 01:28:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5441A04A3 for ; Thu, 8 May 2014 01:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT80r-EjwqjG for ; Thu, 8 May 2014 01:28:25 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 864FA1A04A2 for ; Thu, 8 May 2014 01:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=sZoInYBZrTb6gYOY8VBPUFyNGpnO12JfPYRGs5VcAvg=; b=j1L+5pngW6loWAD9mQUkthCbIh5UGxY6+jCf3oIAiO5I+fWfxtIXlTZDu4eaq6bVDB2ONvSfar/BQTlQwecvz3sdqtVNTnL+e6rDP0Gp6ilyC32ESMIeQerAlvA2hKNPgg5/Xsfc59HbljGGOSnRp7Am82/JxU8K/XntjfQY660=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WiJfz-00058O-MN; Thu, 08 May 2014 10:27:37 +0200 Message-ID: <536B401E.8070502@polarssl.org> Date: Thu, 08 May 2014 10:28:14 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alyssa Rowan , tls@ietf.org References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> In-Reply-To: <536A6F8C.7020702@akr.io> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m9k5jEgLHASxtbJNrEYnW3_RJ8s Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:28:27 -0000 On 07/05/2014 19:38, Alyssa Rowan wrote: > Meanwhile aDH denies us that option, and broadcasts our MITM > susceptibility to Mallory. > [...] > So, what use of anon_DH ciphersuites aren't addressed better by this > method, especially given the very clear additional perpass risk of > keeping them in TLS v1.3 that we've outlined here? How can we do better? > Side note: it seems to me that perpass is short for pervasive passive (surveillance). Would you say the MitM risk you're describing here qualifies as passive? (It might still be cheap enough to be implemented at a large scale by some organisations doing pervasive surveillance, which is a serious problem indeed.) Anyway, I'm not sure an adversary needs aDH as a marker to rather efficiently guess which clients are going perform some kind of server authentication: for example, if the server's cert is self-signed, and the client doesn't perform a TLSA lookup, and the client and the server don't belong to the same organisation, it's quite likely that the client isn't validating. I don't think an adversary needs to be 100% sure here. They can probably also just try to MitM clients and remember for which ones it worked. Manuel. From nobody Thu May 8 06:47:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4771A031B for ; Thu, 8 May 2014 06:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BodUr4O_qs00 for ; Thu, 8 May 2014 06:47:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id F15991A0654 for ; Thu, 8 May 2014 06:47:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 33AAC48215; Thu, 8 May 2014 13:47:31 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 2892548164; Thu, 8 May 2014 13:47:31 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 04C581E041; Thu, 8 May 2014 13:47:31 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 8 May 2014 09:47:15 -0400 From: "Salz, Rich" To: Yoav Nir , Watson Ladd Date: Thu, 8 May 2014 09:47:15 -0400 Thread-Topic: [TLS] The risk of misconfiguration Thread-Index: Ac9qiKHjxQQyx97yQNyyJGx2lumDigAOpdMw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E5A5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> <20140508001532.GG27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E47E@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qYW3A7OHDz4ghdQWgUvmON5ekVw Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 13:47:37 -0000 Yes, perhaps a new alert, e_wtf, MUST/SHOULD be sent if a client offers a n= onsensical combination. Less flippantly a new AlertDescription, unsupported_policy, that can be use= d during a handshake to indicate that a combination of ciphers, extensions,= etc., is not acceptable. We could say a server MUST send it if a client i= n the null/non-null case. But this lets us add other policy concerns in a c= ompatible way. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Thu May 8 07:44:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D391A0007 for ; Thu, 8 May 2014 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvSHMKK6uzTP for ; Thu, 8 May 2014 07:44:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D2E571A0057 for ; Thu, 8 May 2014 07:44:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s48EiEgT007448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 May 2014 16:44:14 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Thu, 8 May 2014 16:44:14 +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: <20140508144414.2D6E71ACFB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qam17YQJh5lZUVnlewp39ckNnW8 Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 14:44:34 -0000 Nico Williams wrote: > On Wed, May 7, 2014 at 12:38 PM, Alyssa Rowan wrote: > > Meanwhile aDH denies us that option, and broadcasts our MITM > > susceptibility to Mallory. > > Don't negotiate anon ciphersuites if they are of no use to you. > > Removing them because of misconfiguration fears is silly: there will > always be possible misconfigurations. Please first address that > argument. And the argument that I shouldn't have to pay for the > additional CPU cycles needed to do pointless (in these use cases) PK. The latter argument is extremely bogus. CPU cycle-wise, the by-far cheapest option for the client is to offer only static RSA cipher suites and entirely skip the validation of the server's certificate, because that is a single public-key RSA operation for the client. We _already_ have a strong warning against DH_anon cipher suites in the TLS v1.2 spec: https://tools.ietf.org/html/rfc5246#page-76 The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the- middle attacks. Using this mode therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.) The problem with unsolicited DH_anon cipher suites being available to an unsuspecting application is that it may easily allow bypassing of the check of the server certificate depending on the API architecture of the SSL stack and how it is used by the application. Configurability of cipher suites (such as HIGH) for administrators MUST NOT allow enabling of DH_anon cipher suites, because this is a request _by_the_administrator_, and not _by_the_application_. DH_anon cipher suites should only be made available, if at all, when the application *CODE* explicitly calls a non-standard API call that signals to the TLS stack, that the application code knows about the resulting semantics and can properly deal with the resulting behaviour. I also believe that the current behaviour of OpenSSL, to enable DH_anon cipher suites when the cipher suite configuration string "HIGH" is used, is extremely unsafe. DH_anon have two more serious drawbacks compared to ignoring an untrusted server certificate: the client can not even "pin" the server's certificate for future connections to the same server (i.e. only an initial leap-of-faith), and it completely precludes the use of a client certificate to authenticate the client to the server. My very personal opinion is that DH_anon cipher suites are pure bloat without value. We do not even implement them in our TLS implementation. But I'm OK with what rfc5246 says about them in the paragraph quoted above. Implementors can just leave them away from their implementations, and the consumers will be *MUCH* better of with the result. I do not see the value in making this availble for an extremely small group of experts like Niko who could devise niche usage scenarios where _they_ could operate them safely with hand-selected and manually hardened application software, compared to the inherent danger to the large unwashed masses (of consumers and app-software). -Martin From nobody Thu May 8 09:05:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912A71A0075 for ; Thu, 8 May 2014 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsEZfQz-Cknu for ; Thu, 8 May 2014 09:05:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A7F331A006B for ; Thu, 8 May 2014 09:05:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E49EF2AAA03; Thu, 8 May 2014 16:05:39 +0000 (UTC) Date: Thu, 8 May 2014 16:05:39 +0000 From: Viktor Dukhovni To: "tls@ietf.org" Message-ID: <20140508160539.GS27883@mournblade.imrryr.org> References: <20140508144414.2D6E71ACFB@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140508144414.2D6E71ACFB@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9siUk5cmYyx7It8Qe7sNFvhpp9g Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:05:51 -0000 On Thu, May 08, 2014 at 04:44:14PM +0200, Martin Rex wrote: > The problem with unsolicited DH_anon cipher suites being available to > an unsuspecting application is that it may easily allow bypassing of > the check of the server certificate depending on the API architecture > of the SSL stack and how it is used by the application. We're back to implementation issues, which should be addressed by implementations. In OpenSSL for example the "DEFAULT" cipher-suite omits anonymous cipher-suites. Non-default cipher-suites are configured by the application. The Postfix SMTP client, for example, automatically appends ":!aNULL" to the application-administrator configured cipher-suite when it wants to elicit a certificate from the remote SMTP server. The Postfix SMTP server automatically appends ":!aNULL" when it wants to solicit a client certificate from the remote SMTP client. This is not rocket science. If you want to add similar safety measures in new high-level APIs, that's fine. I still see no reason to neuter the protocol. > Configurability of cipher suites (such as HIGH) for administrators > MUST NOT allow enabling of DH_anon cipher suites, because this is > a request _by_the_administrator_, and not _by_the_application_. The OpenSSL domain-specific-language for specifying cipher-lists provides a set of elementary properties that can be use to construct cipher lists by combining atoms with "+" (AND) and combining those with ":" (OR), with special semantics for leading "-" and "!". It is somewhat unfortunate that some think of "HIGH" as a way of specifying high security, all it does is select symmetric algorithms with long keys. This is a user-interface issue. There is new code in master that provides security levels, rather than cipher-suite list building blocks. > DH_anon cipher suites should only be made available, if at all, > when the application *CODE* explicitly calls a non-standard > API call that signals to the TLS stack, that the application code > knows about the resulting semantics and can properly deal with > the resulting behaviour. Still not a reason to remove these from the protocol. > I also believe that the current behaviour of OpenSSL, to enable DH_anon > cipher suites when the cipher suite configuration string "HIGH" is > used, is extremely unsafe. I doubt you don't understand "HIGH", so you're likely alluding to the fact that many others might not. That's fine, OpenSSL ciphersuite configuration is too difficult for most users, that's an API issue and an application design issue (when applications simply pass the buck to the user). > DH_anon have two more serious drawbacks compared to ignoring an untrusted > server certificate: the client can not even "pin" the server's certificate > for future connections to the same server (i.e. only an initial leap-of-faith), > and it completely precludes the use of a client certificate to authenticate > the client to the server. Not much use if the application has no code for pinning and no mechanisms to interact with a "user" when pins fail. > My very personal opinion is that DH_anon cipher suites are pure bloat > without value. We do not even implement them in our TLS implementation. Right more "I don't use it, so out it goes". The protocol and many of its implementations are general purpose and serve many use-cases. Custom implementations that make different trade-offs are fine, but are not a valid rationale for neutering the protocol or all implementations. > But I'm OK with what rfc5246 says about them in the paragraph quoted above. > Implementors can just leave them away from their implementations, and > the consumers will be *MUCH* better of with the result. This is certainly true in application-specific products, less so in general-purpose libraries. > I do not see the value in making this availble for an extremely small > group of experts like Nico who could devise niche usage scenarios where > _they_ could operate them safely with hand-selected and manually hardened > application software, compared to the inherent danger to the large > unwashed masses (of consumers and app-software). Well, GSSAPI with channel-binding and without certs is not so exotic. Nor is opportunistic TLS in MTAs. I think it is quite clear that removing ADH and AECDH is an overzealous reaction to heartbleed. If there are concerns about interface safety in particular implementations, they need to be addressed in the right place. (Sometimes in applications rather than in libraries, in which case the library documentation may need to provide better application guidance). -- Viktor. From nobody Thu May 8 09:31:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1E81A006C for ; Thu, 8 May 2014 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjSkkDB23NWG for ; Thu, 8 May 2014 09:31:49 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9F71A006B for ; Thu, 8 May 2014 09:31:49 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so6991711wib.11 for ; Thu, 08 May 2014 09:31: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:date:message-id:subject:from:to :cc:content-type; bh=6I2ryVqWBrd1PX/PcaVfCntXAzDkKB/itUSDNb14xFw=; b=Kg6Yn8yDabsGQ/YuS3Qs6Eeltgik86482o7AyCqZfO/ZqgosLm5ctvGb3bbVXLog5X Ah13nv+jIxS6sSdzj1ydqc8wOAS5M99PLJpiEiJt1BXANfDxG7BLAzh3soLE3y57QyVY sWdqrcHp7UsMSO7J8vOyf0GthxGwKWJSWPbguSSNSROTYQ1yFJzkr6gajIu31WRhp8XA Kz9eGCW30oKdCFzcXLeJAySXPX1ChySwgzkXC9juxnWimKDnY2BzgFkLPgy/pcVTDJsW /lkNkI013H9ZUj1ayp51Hdox4pw9H9lqimT6rzcaEg1fFJ8LH2lU+bn78HBPZUN2gnSI huLA== MIME-Version: 1.0 X-Received: by 10.195.18.8 with SMTP id gi8mr2774184wjd.75.1399566704063; Thu, 08 May 2014 09:31:44 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Thu, 8 May 2014 09:31:43 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E5A5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> <20140508001532.GG27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E47E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E5A5@USMBX1.msg.corp.akamai.com> Date: Thu, 8 May 2014 09:31:43 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WaZGIKfv5lltqKUMqSxElkfHS-Q Cc: "tls@ietf.org" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:31:53 -0000 On 8 May 2014 06:47, Salz, Rich wrote: > Yes, perhaps a new alert, e_wtf, MUST/SHOULD be sent if a client offers a nonsensical combination. I think that is actually necessary. If you intend to prohibit behaviour, it's best if that's enforced. That way the chances of non-conformant behaviour is less likely to propagate. e_wtf sounds like a good name. From nobody Thu May 8 09:38:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE75C1A0075; Thu, 8 May 2014 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8GIE6XKWauL; Thu, 8 May 2014 09:38:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C88F11A0081; Thu, 8 May 2014 09:38:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 829311801C0; Thu, 8 May 2014 09:37:39 -0700 (PDT) To: fl.borchert@gmail.com, rohit@4K-associates.com, lawrence@agranat.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140508163739.829311801C0@rfc-editor.org> Date: Thu, 8 May 2014 09:37:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eRSAyoAPLiiSaaVAqXbQNsnOf6g Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Rejected] RFC2817 (3941) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:38:23 -0000 The following errata report has been rejected for RFC2817, "Upgrading to TLS Within HTTP/1.1". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2817&eid=3941 -------------------------------------- Status: Rejected Type: Editorial Reported by: Florian Borchert Date Reported: 2014-03-31 Rejected by: Stephen Farrell (IESG) Section: 3.1 Original Text ------------- Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be supplied within a Connection header field (section 14.10) Corrected Text -------------- The hyperlink (http://tools.ietf.org/html/rfc2817#section-14.10) to section 14.10 does not work, it should refer to RFC2616: http://tools.ietf.org/html/rfc2616#section-14.42 Notes ----- The hyperlink is an IETF tooling artefact and not part of the RFC, which is clear. --VERIFIER NOTES-- The hyperlink is an IETF tooling artefact and not part of the RFC, which is clear. -------------------------------------- RFC2817 (draft-ietf-tls-http-upgrade-05) -------------------------------------- Title : Upgrading to TLS Within HTTP/1.1 Publication Date : May 2000 Author(s) : R. Khare, S. Lawrence Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu May 8 10:03:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3B11A00D7 for ; Thu, 8 May 2014 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMflqrOMm1mq for ; Thu, 8 May 2014 10:03:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A8E1A1A00D3 for ; Thu, 8 May 2014 10:03:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CF928BE51; Thu, 8 May 2014 18:03:25 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7uyEw1zaUFf; Thu, 8 May 2014 18:03:24 +0100 (IST) Received: from [190.112.52.71] (unknown [190.112.52.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C754DBE47; Thu, 8 May 2014 18:03:23 +0100 (IST) Message-ID: <536BB8D9.90208@cs.tcd.ie> Date: Thu, 08 May 2014 18:03:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , Alyssa Rowan , tls@ietf.org References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <536B401E.8070502@polarssl.org> In-Reply-To: <536B401E.8070502@polarssl.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QLd6He2tAFY3OFjLLYIREZEeslQ Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:03:37 -0000 On 08/05/14 09:28, Manuel Pgouri-Gonnard wrote: > Side note: it seems to me that perpass is short for pervasive passive > (surveillance). I wouldn't sweat about that term. Its just the imperfect name I made up for a mailing list back last summer. It does get used sometimes as a shorthand when we probably would be better saying something longer that uses the term pervasive monitoring, (which is not just passive as you point out) but that's ok for list discussion. S. From nobody Thu May 8 10:09:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9291A1A0065 for ; Thu, 8 May 2014 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUplzg_vdeuB for ; Thu, 8 May 2014 10:09:40 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 654B31A0075 for ; Thu, 8 May 2014 10:09:40 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s48H9Om7025772; Thu, 8 May 2014 13:09:27 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Stephen Farrell , =?utf-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , "Alyssa Rowan" , "tls@ietf.org" Thread-Topic: [TLS] The risk of misconfiguration Thread-Index: AQHPaVvHqPgSudJen0mu5Psxq9JxYps1iogAgAAS5oCAAAE/AIAAB+8AgAD4owCAAI/sgP//vpCA Date: Thu, 8 May 2014 17:09:14 +0000 Message-ID: References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <536B401E.8070502@polarssl.org> <536BB8D9.90208@cs.tcd.ie> In-Reply-To: <536BB8D9.90208@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3482399349_740131" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-08_05:2014-05-08,2014-05-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405080164 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2WnLKp7EL-JI1aGJlO8QAjISEJI Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:09:42 -0000 --B_3482399349_740131 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hmm... Monitoring by definition *is* passive. MITM implies the *ability* to tamper with the traffic, which goes beyond the mere listening capability. On 5/8/14 13:03 , "Stephen Farrell" wrote: >On 08/05/14 09:28, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: >> Side note: it seems to me that perpass is short for pervasive passive >> (surveillance). > >I wouldn't sweat about that term. Its just the imperfect name >I made up for a mailing list back last summer. It does get used >sometimes as a shorthand when we probably would be better saying >something longer that uses the term pervasive monitoring, (which >is not just passive as you point out) but that's ok for list >discussion. --B_3482399349_740131 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCBGvdZ1pD0aYw1Ith51DS6/zN/6si8PkAoWVlqKmI/nEjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MDgxNzA5MDlaMA0GCSqGSIb3 DQEBAQUABIIBAF7dwgAAq8CoO+FxZSb+oPNp0MEEEQKIy4qJ3bUShBKpUAwJCsAkW+VDHXu7 u4/07hr1ZqBbwRPiy8dtsdhIFC/AY0dl22XW7CO9iEqD+qr39jTPCUS32RilIae7tP09gV4m BiW/+ooD8YgveGkwJqK8//PCniqSfJZ/dpcCEwa9p49RGTig1CoV1NVuiDRBll2xV0HjYFSz sh2BCl0t7VtCo4FHQKVApcf+Mp3JMuw+9QhC8WCuNhVVSuwfqNuAcwLyLJSs6q7e+6/iYJ+V 0ogEbGxVvkdtDz/Dfw7UdVCZKDoHYxvinKY6QZS8XlPDHjCX4qm2a0Jd+Eieq+JMJ+w= --B_3482399349_740131-- From nobody Thu May 8 10:35:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494771A0087 for ; Thu, 8 May 2014 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_CDcdgg2p1t for ; Thu, 8 May 2014 10:35:22 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA521A007D for ; Thu, 8 May 2014 10:35:22 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so4025178lbg.2 for ; Thu, 08 May 2014 10:35:17 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mJColv5GmuvfGZnN5uUH0NzBCXNlqweSpA82E0b3M7I=; b=DjwHjVNXEcOrg1+xOSz7bNbc2vD5QyZ3RA/nfQB5ogZGOsf8U/FxW0FkOeGKMI2S35 cqESRD39sIoqrvhbg3HFMOBc+RBdDzPRe1uzFEARMRTTJgZNRW/291EpYKteFXaQseUt MPJpdbE8Lv5YhxwDPzhRY3/WVRBEGNfcxm9VL98ZqfuUveAJWvLefYZfr9Md8Xmd7/Xa p2U+UoE49PEqb85UBBxA7kwQDEEtgbpNCCgDw6Z6Q8hQLTc8EAiKwcyyFw+azGM67e+z hd+/VDxe8flGgAcWp+O37rH4BFqiZVnJBWqVl4AHE7wBUk/Vthey/rgS/NAHDmIj27zL +bcQ== MIME-Version: 1.0 X-Received: by 10.112.164.148 with SMTP id yq20mr5912257lbb.22.1399570517251; Thu, 08 May 2014 10:35:17 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.5.68 with HTTP; Thu, 8 May 2014 10:35:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 10:35:17 -0700 X-Google-Sender-Auth: _wn7UXQ84YGSu-qhLvy6GVFyjxQ Message-ID: From: Adam Langley To: =?UTF-8?Q?Niels_M=C3=B6ller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ats8Kuz8Zo4ccp6zKCgTY4WLG7Y Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:35:24 -0000 On Thu, May 8, 2014 at 12:32 AM, Niels M=C3=B6ller w= rote: > Is this something you'd want to address? After all, high performance is > one of the primary design goals for both chacha and poly1305. The easiest > way I see is to change the formatting for authentication to > > ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext) I think this might be a good idea, thanks! I happen to be meeting with some hardware folks tomorrow (although not about this) and I'll see whether they agree that this would be useful. (Although I'm less sure about moving the lengths to the end.) > There are some other possibilities, taking advantage of the fact that > poly1305 has an unambibuous encoding for short blocks. E.g, if the ad is > the single byte "a", 0x61, zero-padding produces the poly1305 > coefficient 0x10000000000000061, but one could also represent it as > 0x161, as is specified for a final, short, block in poly1305-aes. With > some care, I think one could even drop both length fields. What's needed > is to use the poly1305 short block encoding for the final ad and crypto > text blocks, and in addition make sure that the ad *always* is > terminated with a short block, by adding an empty block (poly1305 > coefficient 0x1) between ad and cryptotext in case the ad length is a > multiple of 16. My feeling is that this is getting too complex for the resulting benefit. > Another minor point: The unused 32 bytes of the first chacha block > (after the 32 bytes used for the poly1305 subkeys), could they be > considered a separate (and optional) output? When chacha-poly1305 is > used in openssh, they encrypt the packet length field separately, and > they seem to be using another instance of chacha for that, with an > independent key. Which seems a bit unnecessary when there are plenty of > left over keystream bytes from the chacha-poly1305 instance they use for > the message payload. Implementations could certainly extract this if they wished, although I'd like to stay in the RFC 5116 framework for AEADs in the spec. For SSH's use, I guess this would complicate their AEAD implementation because they would need to break it up: they need to calculate the first block to decrypt the length and then they can figure out what the ciphertext is. Actually, if they were going to use the leftover keystream bytes from the first block for the length then I would imagine that they would use a separate ChaCha call to calculate it and then, if they decrypt the length and find they have a whole record to process, call the AEAD function, which will redundantly calculate the first block again. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu May 8 11:12:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA001A00B3 for ; Thu, 8 May 2014 11:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNQG07cgZ8gz for ; Thu, 8 May 2014 11:12:40 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 44C8E1A00AE for ; Thu, 8 May 2014 11:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=j/3aZnC4kDeQyw/o3E1DFf+1iO9IPov1fstPlxDahH8=; b=T/AYEt92V/trfFxqwkxleQc7SYOgWP0NUQXr7StQjxOEpQdl1wDBpIoGs0BLbx+0uZoygOrxLhnsfN3qBFNLwOD/1v8Fk3BxjseVX4EOJpj4jeoYQBQQGq3ptes156Ar4JXSELMtdYRXbGXs+1HbVjA90fVN687hK9gaC8Bnkxk=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WiSnH-0005qX-Ed; Thu, 08 May 2014 20:11:49 +0200 Message-ID: <536BC905.2020606@polarssl.org> Date: Thu, 08 May 2014 20:12:21 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Alyssa Rowan , tls@ietf.org References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> <536B401E.8070502@polarssl.org> <536BB8D9.90208@cs.tcd.ie> In-Reply-To: <536BB8D9.90208@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OBpQKJzvZ6VRsSsEleestwCtU7E Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 18:12:41 -0000 On 08/05/2014 19:03, Stephen Farrell wrote: > On 08/05/14 09:28, Manuel Pgouri-Gonnard wrote: >> Side note: it seems to me that perpass is short for pervasive passive >> (surveillance). > > I wouldn't sweat about that term. Its just the imperfect name > I made up for a mailing list back last summer. It does get used > sometimes as a shorthand when we probably would be better saying > something longer that uses the term pervasive monitoring, (which > is not just passive as you point out) but that's ok for list > discussion. > Ok, thanks for this precision. Manuel. From nobody Thu May 8 11:50:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA591A00D3 for ; Thu, 8 May 2014 11:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaNj-CvOgh_y for ; Thu, 8 May 2014 11:50:43 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 00E501A00C2 for ; Thu, 8 May 2014 11:50:42 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 9D5EC1C20D6 for ; Thu, 8 May 2014 20:50:37 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6900C1FE0150; Thu, 8 May 2014 20:50:37 +0200 (CEST) Date: Thu, 8 May 2014 20:50:37 +0200 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20140508185036.GA27641@roeckx.be> References: <20140417203056.GA14753@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140417203056.GA14753@roeckx.be> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Eyk3sQMp_p0D-2J_EDAVbdvvgqU Subject: Re: [TLS] TLS padding breaks ironport X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 18:50:44 -0000 On Thu, Apr 17, 2014 at 10:30:56PM +0200, Kurt Roeckx wrote: > I've just been pointed to: > http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html There is more information here: https://supportforums.cisco.com/announcement/12198406/heartbleed-patched-email-servers-fail-tls-connections-esas-80 Kurt From nobody Thu May 8 12:02:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BE81A00C3 for ; Thu, 8 May 2014 12:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwNbcncjbciG for ; Thu, 8 May 2014 12:02:41 -0700 (PDT) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B71A00FD for ; Thu, 8 May 2014 12:02:40 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s48J2XQ3029602; Thu, 8 May 2014 21:02:33 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s48J2Umk029601; Thu, 8 May 2014 21:02:30 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Thu, 08 May 2014 21:02:30 +0200 In-Reply-To: (Adam Langley's message of "Thu, 8 May 2014 10:35:17 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/D1PtzMboLezj3tIT1gzPHmMmWSA Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 19:02:43 -0000 Adam Langley writes: > On Thu, May 8, 2014 at 12:32 AM, Niels Mller wrote: >> Is this something you'd want to address? After all, high performance is >> one of the primary design goals for both chacha and poly1305. The easiest >> way I see is to change the formatting for authentication to >> >> ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext) > > I think this might be a good idea, thanks! > > I happen to be meeting with some hardware folks tomorrow (although not > about this) and I'll see whether they agree that this would be useful. > (Although I'm less sure about moving the lengths to the end.) I think it's good to have fix alignment for the length fields (even if that's less important than alignment for the cryptotext), and putting both lengths together at the end seemed to make that slightly simpler. But, e.g., ad | pad1 | length(ad) with pad1 smallest needed to get the length(ad) field to *end* at a 16-byte boundary would work fine too. I have no strong opinion here. >> There are some other possibilities, taking advantage of the fact that >> poly1305 has an unambibuous encoding for short blocks. [...] With >> some care, I think one could even drop both length fields. > My feeling is that this is getting too complex for the resulting benefit. I agree the benefit is questionable. You get the possibility to have ad or message larger than 2^64 bytes, which isn't going be terribly useful anytime soon. And it's cleaner in some way, but that's a question of taste; others could argue that taking advantage of poly1305 internals is ugly. Regards, /Niels -- Niels Mller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Sat May 10 18:07:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B351A02B6 for ; Sat, 10 May 2014 18:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G04vrteZis40 for ; Sat, 10 May 2014 18:07:56 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id D7DBD1A0134 for ; Sat, 10 May 2014 18:07:56 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3E059F2C0A6 for ; Sat, 10 May 2014 21:07:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id xnFtcFfMWKlM for ; Sat, 10 May 2014 21:07:20 -0400 (EDT) Received: from [192.168.2.107] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4DCA9F2C0A9 for ; Sat, 10 May 2014 21:07:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Sat, 10 May 2014 19:53:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2B38D7C8-8574-4F52-85EA-0E9AE9D5E0C2@vigilsec.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13E3A2@USMBX1.msg.corp.akamai.com> <536A8804.8000207@akr.io> <20140508001532.GG27883@mournblade.imrryr.org> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BTsRuu5A5lUuKrVzOjBPSUBqN7E Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 01:07:58 -0000 >> The solution to avoid accidental use of NULL ciphers is in the client=20= >> API, no client HELLO should ever include a mixture of NULL and=20 >> non-NULL ciphers-suites. > Why not make that a MUST in the RFC, and the same for anonymous DH? > I think this solves most of the configuration issues without making = any uses impossible. This seems like a good way forward. Russ= From nobody Sun May 11 18:43:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FB1A03B3 for ; Sun, 11 May 2014 18:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUQDLpOOcSNP for ; Sun, 11 May 2014 18:43:40 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 19C311A03AE for ; Sun, 11 May 2014 18:43:39 -0700 (PDT) Received: from [200.24.216.134] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WjfHB-0002Wb-M4; Sun, 11 May 2014 21:43:33 -0400 Date: Sun, 11 May 2014 18:43:33 -0700 From: Bill Frantz To: Watson Ladd X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79f31a90dbcde89fe80978adcca8bf1e7f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 200.24.216.134 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xLfKXzmzooOh7MaSBDqq2zLXB8g Cc: tls@ietf.org Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 01:43:42 -0000 On 5/6/14 at 11:48 AM, watsonbladd@gmail.com (Watson Ladd) wrote: >ciphers and anonymous DH, which very, very few people should ever use. >The other part of the issue is software quality. But a third part of >the issue is the lack of guidance, which UTA was supposedly going to >address. > >So how do we fix this? Well, one thing we can do is ensure that the >least secure options are reasonably secure, so if they are enabled it >isn't a disaster. Authentication-only ciphersuites fail that test. I >appreciate the performance issue, and yes, sometimes you don't need >encryption. But I think the number of people who accidentally enabled >ADH is an order of magnitude more than those who actually wanted it. There are times where encrypting information to obscure its=20 meaning is illegal. One place it is illegal is in amateur radio=20 communications. The FCC recently reaffirmed its ban on=20 encryption for message obfuscation, so this situation is not=20 likely to change soon. The problem comes when amateur radio is used as a fall back for=20 emergency communications. There are times when emergency=20 management agencies communications facilities are either=20 overloaded or fail completely and they turn to amateurs for help. Currently most of the help they get is via classical message=20 passing via voice, morse code, or digital radio -- which can be=20 done in the clear. But things are moving from handing a person a=20 message to be sent to wanting to send data -- spreadsheets etc.=20 A number of amateur radio emergency groups are experimenting=20 with mesh networks, which us IP as their underlying protocol.=20 The NULL cypher suites are ideal because they provide=20 authentication, and replay prevention. Now I recognize that there is a significant footgun in having=20 NULL cypher suites in a mix of protocols offered by a client.=20 One way to reduce the risk is to say, "The server MUST reject=20 any connection attempt where the offered cypher suites include=20 both suites providing encryption and those which have NULL=20 encryption. I notice from Viktor's email that postfix already=20 separates its suites this way. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345=20 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nobody Sun May 11 20:04:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C311A03E1 for ; Sun, 11 May 2014 20:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALVyc2p90vyi for ; Sun, 11 May 2014 20:04:14 -0700 (PDT) Received: from sasl.smtp.pobox.com (sasl.smtp.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id E4E641A03DE for ; Sun, 11 May 2014 20:04:13 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 1B28F1640F; Sun, 11 May 2014 23:04:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=FsTwSLPAkDqS Btk0iMeDWqhTO3s=; b=ldOWJXJYI26f8jrafkJenvaM4MKStvSPjUGEGFEHm4nn +f8C/PezKYQ+8ZJr55XUEJPpmSTyKwZ4w7CyReSFqmB9vg5Jt6sSB0ry26arDkTo VDHE/ULm0vDp5om+1LznH7ru5XdiTuBYGBizVUc3826kcoudaV/1gUfFypE0ejk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=o+6qaX um+xaqH1QJOa6v4ymLUEC6/foz1yq1XdV3d5QrhWJpFfEylnvv/S9SQdTmfojmvm 6JLL12Ycbw5SoV5kEg+LnlYvkhIrN9/B41Aroor8CheMOvw85/Jvt/+bJl5GcQhZ lqfYUW4F9H6+X4YGtyhMm/h8BfcMOynnOjAb8= Received: from pb-sasl0.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 121091640B; Sun, 11 May 2014 23:04:07 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl0.pobox.com (Postfix) with ESMTPSA id 5D1081640A; Sun, 11 May 2014 23:04:04 -0400 (EDT) Message-ID: <53703A23.4000304@pobox.com> Date: Sun, 11 May 2014 20:04:03 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bill Frantz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 1363DC34-D982-11E3-82FE-D2BAB895B7A1-38729857!pb-sasl0.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HYBcDtnBRAjtqv_NJV5ffcYSBS0 Cc: tls@ietf.org Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 03:04:15 -0000 Bill Frantz wrote: > > Now I recognize that there is a significant footgun in having NULL > cypher suites in a mix of protocols offered by a client. One way to > reduce the risk is to say, "The server MUST reject any connection > attempt where the offered cypher suites include both suites providing > encryption and those which have NULL encryption. Why not have the server choose a non-NULL cipher suite if both types are offered instead of rejecting the connection? Mike From nobody Sun May 11 20:17:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3E1A03DF for ; Sun, 11 May 2014 20:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2hinJqe9mt9 for ; Sun, 11 May 2014 20:17:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 829951A03D8 for ; Sun, 11 May 2014 20:17:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 781D12AB0F7; Mon, 12 May 2014 03:16:54 +0000 (UTC) Date: Mon, 12 May 2014 03:16:54 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140512031652.GS27883@mournblade.imrryr.org> References: <53703A23.4000304@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53703A23.4000304@pobox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g6ZiD1NjQjQOwkGb8llWKXGzfkk Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 03:17:06 -0000 On Sun, May 11, 2014 at 08:04:03PM -0700, Michael D'Errico wrote: > Bill Frantz wrote: > > > >Now I recognize that there is a significant footgun in having NULL cypher > >suites in a mix of protocols offered by a client. One way to reduce the > >risk is to say, "The server MUST reject any connection attempt where the > >offered cypher suites include both suites providing encryption and those > >which have NULL encryption. > > Why not have the server choose a non-NULL cipher suite if both types > are offered instead of rejecting the connection? I am not convined that any special action should be taken on the server side. My original suggestion was that client implementations could by default attempt to catch some configuration errors (user interface improvement). Server-side enforcement (effectively a protocol change) is likely unnecessary complexity. There may even be use-cases in which the client prefers authenticated NULL ciphers, but if the choice is between a handshake failure or being forced to encrypt, is willing to encrypt. I expect this to be quite rare, but there is no compelling reason to rule this out. Clients that offer NULL ciphers to servers not a-priori known to support them will almost always find their offer declined. So on balance I don't think it would be appropriate to *require* any particular server behaviour here, however implementations MAY implement optional features that enforce sensible policies at either end. -- Viktor. From nobody Mon May 12 03:58:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCAD1A0675 for ; Mon, 12 May 2014 03:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.993 X-Spam-Level: * X-Spam-Status: No, score=1.993 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BXcjyVuvakA for ; Mon, 12 May 2014 03:58:03 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 722A01A05D1 for ; Mon, 12 May 2014 03:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=offspark.com; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:To:From; bh=TIM8+LdeS0i2GiJUUAL2y2UAhfwmis2aesXhF6+aSes=; b=kw+oxYj4TiVSCnCc1t/U3egnl43PDM8nimRqHPyGJrDuEw3UirUYkFoxYKjKPUj2ry5S/LC/XuwhrG1/ZGtWvSr1sW6TW0OmUIQI37FAQVHpeNVUPze+YHhMo3ihL3N1e0lDv9tJeHMBfWUlYnkv8s3IwzoTf9+HC1/bBTvYPOE=; Received: from 5354a6da.cm-6-5c.dynamic.ziggo.nl ([83.84.166.218] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Wjnuu-0002Qe-5q for tls@ietf.org; Mon, 12 May 2014 12:57:08 +0200 From: "Paul Bakker" To: Date: Mon, 12 May 2014 12:57:51 +0200 Message-ID: <021801cf6dd1$0826d9b0$18748d10$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac9t0NT9TbDNPI1yRE+OD3gAEV+z7w== Content-Language: nl X-SA-Exim-Connect-IP: 83.84.166.218 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xwTuo2lab10YkCHjahR549Tf3r4 Subject: [TLS] Server-side fragment size signalling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 10:58:04 -0000 Hi, While we are on the TLS 1.3 discussion, I would like to start a discussion on bringing equality to low-footprint servers compared to the options clients have now. Currently low-footprint clients that have very restricted memory resources are able to indicate using smaller send/receive buffers with the max_fragment_length extension (If the server supports the RFC 6066). This removes the need to be able to accept packets 16k bytes in size, which is often one of the largest 'permanent' buffers you need in low-footprint environments. But low-footprint servers that get connected to by high-footprint clients don't have this option. They cannot indicate to the client that they would only like to receive fragments with a maximum size of 2^9. As the world of small-footprint devices is still growing rapidly (i.e. Internet of Things), life for low-footprint servers should be viable as well. The simplest solution to this is to modify the current extension's definition (Other RFC but as follows: * Change: "In order to negotiate smaller maximum fragment lengths, clients MAY include an extension of type "max_fragment_length" in the (extended) client hello. " Into: "If a clients support this extension, clients SHALL include an extension of type "max_fragment_length" in the (extended) client hello." * And: "The "extension_data" field of this extension SHALL contain a "MaxFragmentLength" whose value is the same as the requested maximum fragment length." Into: "The "extension_data" field of this extension SHALL contain a "MaxFragmentLength" whose value is the same or lower as the requested maximum fragment length." An alternative is to allow the server to send a max_fragment_length extension even if it did not receive one from the client, but this violates the 'standard way' and the server does not know if the client even supports the max_fragment_length extension. I'm actively looking for feedback or alternatives that people have in mind! Best regards, Paul Bakker Lead maintainer PolarSSL From nobody Mon May 12 11:02:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818C81A076E for ; Mon, 12 May 2014 11:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNHHubIt405n for ; Mon, 12 May 2014 11:02:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 55CEE1A076A for ; Mon, 12 May 2014 11:02:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="110396737" X-IPAS-Result: AqoEADD7RVPAqArr/2dsb2JhbABZg0FXgw65Mx2HNRmBHnSCJQEBAQECAQEBASARNwMLBQsCAQgNAQMEAQEDAgYdAwICAiULFAEICAIEAQ0FCBECh1kVqQijCBMEgSmMWzcxB4JvNYEUBJ9ZjneCKw Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 May 2014 18:01:54 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Mon, 12 May 2014 11:01:53 -0700 From: David Holmes To: Eric Rescorla , Brian Sniffen Thread-Topic: [TLS] About encrypting SNI Thread-Index: AQHPWnp40xDFX3CqmkSJdQlISxBKe5s9Yd7Q Date: Mon, 12 May 2014 18:01:53 +0000 Deferred-Delivery: Mon, 12 May 2014 18:01:00 +0000 Message-ID: <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/D0UtYagUlu9vqJy0AX1xsRdsF58 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:02:02 -0000 4p6iIHNvIGEgc2VydmVyIHVuZGVyIGxvYWQgY2FuLCBpbiB0aGUgaW5pdGlhbCBvcHBvcnR1bmlz dGljIGVuY3J5cHRpb24gcGhhc2UsIHB1c2ggYmFjayB0byBhIGNsaWVudCBhbmQgYXNrIGZvciBh IHB1enpsZSB0byBiZSBzb2x2ZWQ/DQoNCkkgd2FzIGRlc2NyaWJpbmcgdGhpcyBpZGVhIHRvIGEg Y29sbGVhZ3VlLCBhbmQgdGhlIGZpcnN0IHRoaW5nIGhlIHNhaWQgd2FzICJjb3VsZCB5b3UgaGF2 ZSB0aGUgY2xpZW50IG1pbmUgc29tZSBiaXRjb2luIGZvciB5b3U/IEFzIGEgc2hvdyBvZiBnb29k IGZhaXRoPyINCg0KVHdvIHByb2JsZW1zIHNwcnVuZyB0byBtaW5kIHdpdGggYSBiaXRjb2luIG1p bmluZyBzb2x1dGlvbiAtIHVuZXRoaWNhbCBzZXJ2ZXJzIHdvdWxkIGJlIGdhbWluZyBjbGllbnRz IHRvIGRvIGNvbXB1dGF0aW9uIGZvciB0aGVtLiBTZWNvbmQsIHRoaXMgd291bGQgYWxzbyBhIGNh dXNlIGEgcHJvYmxlbSBmb3IgbW9iaWxlIGhhbmRzZXRzIHdoZXJlIENQVSA9IGJhdHRlcnkgbGlm ZS4NCg0KQnV0IEkgdGhpbmsgdGhlIHB1enpsZSBpZGVhIGhhcyBtZXJpdCwgZXNwZWNpYWxseSBp ZiBpdCdzIG5vdCBhIHJlcXVpcmVkIGNoYWxsZW5nZSA9IHRoYXQgaXMsIG9ubHkgaXNzdWVkIHdo ZW4gc2VydmVyIGlzIHVuZGVyIGxvYWQuDQoNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUaHVyc2RheSwg QXByaWwgMTcsIDIwMTQgMjoyMCBQTQ0KVG86IEJyaWFuIFNuaWZmZW4NCkNjOiB0bHNAaWV0Zi5v cmc7IEFuZHkgTHV0b21pcnNraQ0KU3ViamVjdDogUmU6IFtUTFNdIEFib3V0IGVuY3J5cHRpbmcg U05JDQoNCk9uIFRodSwgQXByIDE3LCAyMDE0IGF0IDEyOjU5IFBNLCBCcmlhbiBTbmlmZmVuIDxi c25pZmZlbkBha2FtYWkuY29tPiB3cm90ZToNCkkgaGVzaXRhdGUgdG8gYXNrLCBidXQ6IGlzIGl0 IHBsYXVzaWJsZSB0byByZS1vcGVuIHRoZSBwcm9vZi1vZi13b3JrDQpjb252ZXJzYXRpb24sIHNv IGEgc2VydmVyIHVuZGVyIGxvYWQgY2FuLCBpbiB0aGUgaW5pdGlhbCBvcHBvcnR1bmlzdGljDQpl bmNyeXB0aW9uIHBoYXNlLCBwdXNoIGJhY2sgdG8gYSBjbGllbnQgYW5kIGFzayBmb3IgYSBwdXp6 bGUgdG8gYmUNCnNvbHZlZD8NCg0KSSBkb24ndCB0aGluayBpdCdzIGltcGxhdXNpYmxlICh0aG91 Z2ggSSdtIG5vdCBjb21wbGV0ZWx5IHNvbGQgeWV0KS4NCg0KT25lIGNvbmNlcm4gSSB3b3VsZCBo YXZlIGlzIHdoZXRoZXIgd2UgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB3ZWxsDQplbm91Z2ggdG8g YWN0dWFsbHkgc3BlY2lmeSB0aGlzLiBJJ20gbm90IGFuIGV4cGVydCBpbiB0aGlzIGFyZWEsIGJ1 dCB3ZXJlbid0DQp0aGVyZSBhIGJ1bmNoIG9mIGNvbmNlcm5zIGFib3V0IGRlc2lnbmluZyBwdXp6 bGVzIHRoYXQgd2VyZSBlZmZlY3RpdmUNCndpdGhvdXQgYmVpbmcgcHJvaGliaXRpdmVseSBleHBl bnNpdmUgZm9yIG1vYmlsZSBkZXZpY2VzPyBIb3cgd291bGQNCndlIGRlc2lnbiBhIG5ldyBraW5k IG9mIHB1enpsZSAoQXMgb3Bwb3NlZCB0byBtZXNzaW5nIHdpdGggdGhlIHB1enpsZQ0Kd29yayBm YWN0b3IpIGFuZCB0aGVuIHJvbGwgaXQgb3V0Pw0KDQotRWtyDQoNCj4gSSB3b25kZXIgaWYgdGhl cmUncyBhIHdheSB0byB0ZXN0IGEgbGFyZ2UgbnVtYmVyIG9mIHByaXZhdGUga2V5cyBhdA0KPiBv bmNlLiDCoElmIHNvLCB0aGVuIHRoZSBjb3N0IGRyb3BzIHRvIE8obG9nIE4pLiDCoE9mZiB0aGUg dG9wIG9mIG15DQo+IGhlYWQsIEkgY2FuJ3QgdGhpbmsgb2YgYSBjcnlwdG9zeXN0ZW0gd2l0aCB0 aGF0IHByb3BlcnR5Lg0KSSBjZXJ0YWlubHkgZG9uJ3QgZXhwZWN0IHRvIGZpbmQgYW55ICpwYWly KiBvZiBjcnlwdG9zeXN0ZW1zIHdpdGggdGhhdA0KcHJvcGVydHksIGFuZCBjb250aW51ZSB0byBt YWludGFpbiB0aGF0IGluIDMgeWVhcnMgd2Ugd29uJ3QgZmluZCB0d28gYmlnDQpvcmdhbml6YXRp b25zIHdpbGxpbmcgdG8gdXNlIGV4YWN0bHkgdGhlIHNhbWUgY3J5cHRvLg0KDQotQnJpYW4NCg0K LS0NCkJyaWFuIFNuaWZmZW4NCkluZm9ybWF0aW9uIFNlY3VyaXR5DQpBa2FtYWkgVGVjaG5vbG9n aWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExT IG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Rscw0KDQo= From nobody Mon May 12 11:22:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9981A0766 for ; Mon, 12 May 2014 11:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXWAFRIrRLG6 for ; Mon, 12 May 2014 11:22:41 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFD61A075C for ; Mon, 12 May 2014 11:22:41 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 21EA02861D; Mon, 12 May 2014 18:22:35 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 05B42285F0; Mon, 12 May 2014 18:22:35 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 01AC92026; Mon, 12 May 2014 18:22:35 +0000 (GMT) Received: from Tereva.local (172.19.41.163) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 12 May 2014 14:22:34 -0400 From: Brian Sniffen To: David Holmes , Eric Rescorla In-Reply-To: <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Mon, 12 May 2014 14:22:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qWNE6Ry76ER7HahQKxdEPkO9onA Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:22:44 -0000 David Holmes writes: > =E2=9E=A2 so a server under load can, in the initial opportunistic encryp= tion phase, push back to a client and ask for a puzzle to be solved? > > I was describing this idea to a colleague, and the first thing he said wa= s "could you have the client mine some bitcoin for you? As a show of good f= aith?" Bitcoin's also hard to check: if the client says it found no bitcoin in a particular region, how do you know? And a whole bitcoin's too much to ask. An identity scheme tied to giving away bitcoin---much like a credit rating ties to many transactions profitable for the counterparty---has a lot in its favor. It would make a great (research) extension on top of TLS 1.3, and I hope that any puzzle mechanism will be flexible enough to support that. -Brian > Two problems sprung to mind with a bitcoin mining solution - unethical se= rvers would be gaming clients to do computation for them. Second, this woul= d also a cause a problem for mobile handsets where CPU =3D battery life. > > But I think the puzzle idea has merit, especially if it's not a required = challenge =3D that is, only issued when server is under load. > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Thursday, April 17, 2014 2:20 PM > To: Brian Sniffen > Cc: tls@ietf.org; Andy Lutomirski > Subject: Re: [TLS] About encrypting SNI > > On Thu, Apr 17, 2014 at 12:59 PM, Brian Sniffen wro= te: > I hesitate to ask, but: is it plausible to re-open the proof-of-work > conversation, so a server under load can, in the initial opportunistic > encryption phase, push back to a client and ask for a puzzle to be > solved? > > I don't think it's implausible (though I'm not completely sold yet). > > One concern I would have is whether we understand the problem well > enough to actually specify this. I'm not an expert in this area, but were= n't > there a bunch of concerns about designing puzzles that were effective > without being prohibitively expensive for mobile devices? How would > we design a new kind of puzzle (As opposed to messing with the puzzle > work factor) and then roll it out? > > -Ekr > >> I wonder if there's a way to test a large number of private keys at >> once. =C2=A0If so, then the cost drops to O(log N). =C2=A0Off the top of= my >> head, I can't think of a cryptosystem with that property. > I certainly don't expect to find any *pair* of cryptosystems with that > property, and continue to maintain that in 3 years we won't find two big > organizations willing to use exactly the same crypto. > > -Brian > > -- > Brian Sniffen > Information Security > Akamai Technologies > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Brian Sniffen Information Security Akamai Technologies From nobody Mon May 12 11:26:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7C01A077D for ; Mon, 12 May 2014 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5DAYn2bQE1T for ; Mon, 12 May 2014 11:26:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3811A1A0727 for ; Mon, 12 May 2014 11:26:15 -0700 (PDT) Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB556.namprd03.prod.outlook.com (10.141.142.145) with Microsoft SMTP Server (TLS) id 15.0.939.12; Mon, 12 May 2014 18:26:08 +0000 Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.0939.000; Mon, 12 May 2014 18:26:08 +0000 From: Marsh Ray To: David Holmes , Eric Rescorla , "Brian Sniffen" Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9SbYXhdiDYEiy3R5ypSW7DwlHnYAFrg7cAAAF5JoAAAihjAAAEDgQAAAduIoAABKNTgAAjtNIAAAtlDQAAFRL3gAABWWmAAABDDoAACPT9gAAAc8kAAA/5B4AAAMGRAAAVQESAAANUywAAA59MgAAAme4AAAaECQAAALFTAATkec2AAABi72A= Date: Mon, 12 May 2014 18:26:08 +0000 Message-ID: <26ad05857efc44758420e30fdeee5f4d@BY2PR03MB554.namprd03.prod.outlook.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(31966008)(81342001)(21056001)(81542001)(64706001)(74502001)(86362001)(20776003)(76482001)(19580405001)(83322001)(77982001)(74662001)(101416001)(77096999)(85852003)(54356999)(4396001)(92566001)(76176999)(2656002)(87936001)(83072002)(74316001)(50986999)(46102001)(99286001)(79102001)(33646001)(80022001)(19580395003)(99396002)(76576001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB556; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=maray@microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6JdPq_8L4YelAIwVSVx7ACeses4 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:26:26 -0000 RnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZp ZCBIb2xtZXMNCj4g4p6iIHNvIGEgc2VydmVyIHVuZGVyIGxvYWQgY2FuLCBpbiB0aGUgaW5pdGlh bCBvcHBvcnR1bmlzdGljIGVuY3J5cHRpb24gcGhhc2UsIHB1c2ggYmFjayB0byBhIGNsaWVudCBh bmQgYXNrIGZvciBhIHB1enpsZSB0byBiZSBzb2x2ZWQ/DQo+DQo+IEkgd2FzIGRlc2NyaWJpbmcg dGhpcyBpZGVhIHRvIGEgY29sbGVhZ3VlLCBhbmQgdGhlIGZpcnN0IHRoaW5nIGhlDQo+IHNhaWQg d2FzICJjb3VsZCB5b3UgaGF2ZSB0aGUgY2xpZW50IG1pbmUgc29tZSBiaXRjb2luIGZvciB5b3U/ IEFzIGEgc2hvdyBvZiBnb29kIGZhaXRoPyINCg0KRXZlbiBiZXR0ZXIsIGFzayB0aGUgY2xpZW50 IHRvIHBlcmZvcm0gc29tZSBjb21wdXRhdGlvbiB3aGljaCB3aWxsIHVzZWZ1bGx5IG9mZmxvYWQg d29yayBmcm9tIHRoZSBzZXJ2ZXIgc29tZWhvdy4NCg0KRS5nLiwgYSByaWRpY3Vsb3VzIG5hw692 ZSBzdHJhd21hbiBpZGVhIHdvdWxkIGJlIGZvciB0aGUgY2xpZW50IHRvIHBlcmZvcm0gdGhlIHNl cnZlci1zaWRlIG1vZHVsYXIgZXhwb25lbnRpYXRpb24gbmVlZGVkIGZvciBhbm90aGVyIGNsaWVu dCdzIERIRSBjb25uZWN0aW9uLiBPYnZpb3VzbHkgdGhpcyB3b3VsZCBub3QgYmUgc2VjdXJlLCBi dXQgcGVyaGFwcyBzb21lIDIxc3QgY2VudHVyeSBjcnlwdG9zeXN0ZW0gY291bGQgZG8gaXQgc2Vj dXJlbHkuIE5ldmVydGhlbGVzcywgdGhlcmUgd291bGQgc3RpbGwgYmUgaXNzdWVzIGFib3V0IHJl bGlhYmlsaXR5IGFuZCBsYXRlbmN5Lg0KDQotIE1hcnNoDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCk15IG93biBwZXJzb25hbCBvcGluaW9ucywgYm9pbGVycGxhdGUgZGlzY2xhaW1lcnMgYXBw bHkuDQoNCg== From nobody Mon May 12 11:31:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C5C1A0735 for ; Mon, 12 May 2014 11:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um59el9QzgnD for ; Mon, 12 May 2014 11:31:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 057381A0728 for ; Mon, 12 May 2014 11:31:18 -0700 (PDT) Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB553.namprd03.prod.outlook.com (10.141.141.155) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 12 May 2014 18:31:03 +0000 Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.0939.000; Mon, 12 May 2014 18:31:03 +0000 From: Marsh Ray To: Brian Sniffen , David Holmes , "Eric Rescorla" Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9SbYXhdiDYEiy3R5ypSW7DwlHnYAFrg7cAAAF5JoAAAihjAAAEDgQAAAduIoAABKNTgAAjtNIAAAtlDQAAFRL3gAABWWmAAABDDoAACPT9gAAAc8kAAA/5B4AAAMGRAAAVQESAAANUywAAA59MgAAAme4AAAaECQAAALFTAATkec2AAAC47AAAAAbk0A== Date: Mon, 12 May 2014 18:31:03 +0000 Message-ID: <15d5a50ed2244e8595edfa57d7055e2b@BY2PR03MB554.namprd03.prod.outlook.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(51704005)(54356999)(50986999)(4396001)(76176999)(21056001)(15975445006)(79102001)(81542001)(76576001)(64706001)(87936001)(74316001)(33646001)(2656002)(92566001)(85852003)(99286001)(99396002)(83072002)(74502001)(15202345003)(77982001)(19580405001)(101416001)(80022001)(86362001)(46102001)(81342001)(77096999)(83322001)(76482001)(19580395003)(31966008)(20776003)(74662001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB553; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=maray@microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RLoo6mAaQXj4tLMIdqkJ9da61RU Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:31:23 -0000 RnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBTbmlmZmVuDQo+DQo+IEJpdGNvaW4ncyBhbHNvIGhhcmQgdG8gY2hlY2s6IGlmIHRoZSBjbGll bnQgc2F5cyBpdCBmb3VuZCBubyBiaXRjb2luIGluIGENCj4gcGFydGljdWxhciByZWdpb24sIGhv dyBkbyB5b3Uga25vdz8gIEFuZCBhIHdob2xlIGJpdGNvaW4ncyB0b28NCj4gbXVjaCB0byBhc2su DQo+IA0KPiBBbiBpZGVudGl0eSBzY2hlbWUgdGllZCB0byBnaXZpbmcgYXdheSBiaXRjb2luLS0t bXVjaCBsaWtlIGEgY3JlZGl0DQo+IHJhdGluZyB0aWVzIHRvIG1hbnkgdHJhbnNhY3Rpb25zIHBy b2ZpdGFibGUgZm9yIHRoZSBjb3VudGVycGFydHktLS0NCj4gaGFzIGEgbG90IGluIGl0cyBmYXZv ci4gIEl0IHdvdWxkIG1ha2UgYSBncmVhdCAocmVzZWFyY2gpIGV4dGVuc2lvbg0KPiBvbiB0b3Ag b2YgVExTIDEuMywgYW5kIEkgaG9wZSB0aGF0IGFueSBwdXp6bGUgbWVjaGFuaXNtIHdpbGwgYmUN Cj4gZmxleGlibGUgZW5vdWdoIHRvIHN1cHBvcnQgdGhhdC4NCg0KWWVhcnMgYmFjaywgTWljcm9z b2Z0IHdhcyBsb29raW5nIGludG8gYSBwcm9vZi1vZi13b3JrIHNjaGVtZSBmb3IgYW50aXNwYW0g c2VuZGVyLXBheXMgZW1haWwuDQpodHRwOi8vcmVzZWFyY2gubWljcm9zb2Z0LmNvbS9lbi11cy9w cm9qZWN0cy9wZW5ueWJsYWNrLw0KDQpPbmUgY2hhbGxlbmdlIGlzIHRoYXQgYm90bmV0cyAodGhh dCBhcmUgY29uZHVpdHMgZm9yIG1vc3Qgb2YgdGhlIHNwYW0pIGFsc28gaGF2ZSBwbGVudHkgb2Yg c3BhcmUgQ1BVIGNhcGFjaXR5Lg0KDQotIE1hcnNoDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkJvaWxlcnBsYXRlIGRpc2NsYWltZXJzIGFwcGx5Lg0KDQo= From nobody Mon May 12 14:28:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A891A0772 for ; Mon, 12 May 2014 14:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffbGy5AUgOco for ; Mon, 12 May 2014 14:28:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C40C71A035C for ; Mon, 12 May 2014 14:28:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB283BE74; Mon, 12 May 2014 22:28:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11p+mov48qeh; Mon, 12 May 2014 22:28:00 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.66.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ACFDEBE80; Mon, 12 May 2014 22:27:59 +0100 (IST) Message-ID: <53713CDE.1070308@cs.tcd.ie> Date: Mon, 12 May 2014 22:27:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sfriedl@cisco.com, andreipo@microsoft.com, agl@google.com, emile.stephan@orange.com References: <20140512210747.10675.45300.idtracker@ietfa.amsl.com> In-Reply-To: <20140512210747.10675.45300.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vVCg1WXLSuGvcBAdd2X98zRbVgU Cc: Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org Subject: Re: [TLS] IPR Disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:28:11 -0000 Hi All, On 12/05/14 22:07, IETF Secretariat wrote: > > Dear Stephan Friedl, Andrey Popov, Adam Langley, Stephan Emile: > > An IPR disclosure that pertains to your Internet-Draft entitled "Transport > Layer Security (TLS) Application Layer Protocol Negotiation Extension" (draft- > ietf-tls-applayerprotoneg) was submitted to the IETF Secretariat on 2014-05-12 > and has been posted on the "IETF Page of Intellectual Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/2357/). The title of the IPR > disclosure is "INEOVATION's Statement about IPR related to draft-ietf-tls- > applayerprotoneg-05.""); After the draft was placed in the RFC editor's queue we got a heads-up that this might be coming so I asked the RFC editor to hold publication for a bit hoping we'd find out more which we now have. So if the WG wanted to make some change to the document, that is still possible. If the WG are happy to go ahead then I can ask the RFC editor to proceed as normal. I'll wait for the WG chairs to tell me what action to take. Regards, S. > > The IETF Secretariat > > > From nobody Mon May 12 15:19:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4F1A078C for ; Mon, 12 May 2014 15:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdnuXXPWcoqR for ; Mon, 12 May 2014 15:19:24 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 191571A0788 for ; Mon, 12 May 2014 15:19:23 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id r20so5296821wiv.7 for ; Mon, 12 May 2014 15:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ehFMwdnbcGDlLqszln+Z+ZerEc/opl31gSyJPz4GB1Q=; b=ukePv3HR8ZjfEuPU7LyiC9d/4841OkLvuvTGd/54rF84PEJiCPvSSh/Y0F5k/enjzd VV/PExEZd3F4R4mL1+nhxPopfh0kbTdJ3G6XTFYlUyQ/Rg0X1tVMYNhiAg4QtVyJUiaS SHQQ4+5RQmZaKEfisvUe7v01oRGhpjGSUhphZZRdPEZCQ70LDMTTgTXD0ql1qNwr0wFG qI9mxRg7Rckk3elXH6M2Za3bPOKZY233TReHYNML9XcOmDjFP1FDOO1ngCCQzgdgEopp unHgh1PBhxWkwd3KeN0SfM4RtdycZxmQUYkLLNKn8AJ0dnJqNcEYQYQ3WO5gVFfFwjVy KI/Q== X-Received: by 10.194.7.232 with SMTP id m8mr2552739wja.47.1399933157552; Mon, 12 May 2014 15:19:17 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id rw4sm19583139wjb.44.2014.05.12.15.19.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 15:19:16 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <53713CDE.1070308@cs.tcd.ie> Date: Tue, 13 May 2014 01:19:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A5F4392-1553-4F7E-BD72-D1F44B8E83A3@gmail.com> References: <20140512210747.10675.45300.idtracker@ietfa.amsl.com> <53713CDE.1070308@cs.tcd.ie> To: Stephen Farrell , "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fhNB8zwu7HEj2tuieRuHFMHlri0 Subject: Re: [TLS] IPR Disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 22:19:26 -0000 On May 13, 2014, at 12:27 AM, Stephen Farrell = wrote: >=20 > Hi All, >=20 > On 12/05/14 22:07, IETF Secretariat wrote: >>=20 >> Dear Stephan Friedl, Andrey Popov, Adam Langley, Stephan Emile: >>=20 >> An IPR disclosure that pertains to your Internet-Draft entitled = "Transport >> Layer Security (TLS) Application Layer Protocol Negotiation = Extension" (draft- >> ietf-tls-applayerprotoneg) was submitted to the IETF Secretariat on = 2014-05-12 >> and has been posted on the "IETF Page of Intellectual Property Rights >> Disclosures" (https://datatracker.ietf.org/ipr/2357/). The title of = the IPR >> disclosure is "INEOVATION's Statement about IPR related to = draft-ietf-tls- >> applayerprotoneg-05.""); >=20 > After the draft was placed in the RFC editor's queue we got > a heads-up that this might be coming so I asked the RFC editor > to hold publication for a bit hoping we'd find out more which > we now have. >=20 > So if the WG wanted to make some change to the document, > that is still possible. If the WG are happy to go ahead then > I can ask the RFC editor to proceed as normal. IANAL, but that patent seems to be about multiplexing multiple = applications within a single session, so more like SSL-VPN than just = TLS. In fact the patent talks about VPNs in the description part.=20 More specifically, all the application negotiation in the patent happens = in application data records, not handshake records. So it=92s = multiplexing at the application layer, vs selection at the handshake. = Doesn=92t seem to me that it applies.=20 But regardless of applicability, the IPR disclosure says this: = =93Licensing Declaration to be Provided Later.=94 How can we make any = rational decisions based on that? Yoav From nobody Mon May 12 17:39:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77561A07B8 for ; Mon, 12 May 2014 17:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGMhEVzn2Mnt for ; Mon, 12 May 2014 17:39:01 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8E1A07B3 for ; Mon, 12 May 2014 17:39:01 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 021562007F227 for ; Mon, 12 May 2014 17:38:55 -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=5+0o2+keullUilSu6z9h aMHy9vY=; b=jprf2VL9IapL/I5BIjP4sDFpOda5t5bxMX7w2gQvGt6fLekRH3AD IoMKMGexDprpLVGIs+zusHJ5Eb2QDecm5pLad9jPbSq+t9XdkudQG1s3d3XTftyM 1l+UhaRlj2L4J0hyFRbG/clIf1L3OOuNFXzJ7VJQOn9QC5OkmhnkUsc= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id ABB9F2007F226 for ; Mon, 12 May 2014 17:38:54 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so5403813wiw.16 for ; Mon, 12 May 2014 17:38:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr17940190wiw.5.1399941533290; Mon, 12 May 2014 17:38:53 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 12 May 2014 17:38:53 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Mon, 12 May 2014 19:38:53 -0500 Message-ID: From: Nico Williams To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bpW2rOvEoQxFV7XqhmsQYQLN_ns Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 00:39:02 -0000 On Wed, Apr 16, 2014 at 8:53 AM, Tom Ritter wrote: > ....But... There once was a thing called DNSSEC Stapled Certs > (https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a > SSL certificate had a chain of DNSSEC signatures in it, validating it > via DANE (or at that time, a DANE-like mechanism.) It violates a I've been thinking of this for a while... > layering principal that people hold dearly, shoving DNS information in > other corners it shouldn't be. But I think it would be necessary for > the wildcard approach to be reliable for clients like browsers. Layers aren't pure though. Some things show through the various layers' interfaces, sometimes several layers through. For example, many apps have to deal with all of DNS and TCP/IP, with IP addresses and TCP port numbers used together in socket APIs. It might have been a lot better if the sockets APIs had deal with hostnames from the start, but here we are. Abstractions are leaky. Now in this case I think saving a client a number of DNSSEC lookups could be convenient. We should -of course- make sure that this works out securely -- we don't want to end up with a cache poisoning attack here. Nico -- From nobody Mon May 12 17:46:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259631A0382 for ; Mon, 12 May 2014 17:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa05v7ic06tZ for ; Mon, 12 May 2014 17:45:58 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id DBA3F1A037F for ; Mon, 12 May 2014 17:45:57 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jw12so9697553veb.5 for ; Mon, 12 May 2014 17:45:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UjdXezuQAHUK6cu1J0T7mcaQl3HU+jmEmnt4M8sBopk=; b=aeUZcExzaIy9umkjnbk4USY++ClK9ukZhsd22xaUJfwMD454SBL6bXuSvq1J+OjIx+ 4Zq0Bwe/d2JZNYLl5o1swDg476ayv+rAIgWpVh4/VdRk+wLoWBXIhnosHp8dqsHYNZDa gnf3wgTnpN64oll1XqJsLDz6+vqTi3rTtECLN4EbzlfgJzrcjegUUOG5So6R1SuS30kh sVimKYF3qYO8ww+u2s6w3hZEtXSQBtUXXlJtw6x9ZiwjSrpqQ/AaFX3sYrof9GoGEU1/ PeE72vgelqh2E9Xlq+7VzILzOGeApkCEmMnaIKrJyj9ki69Px3T7O52gtnA7wfRQAyAE DtQQ== X-Gm-Message-State: ALoCoQmaHnoyzLG8lc9RuNRafAxApc/WxhFWq7xTZ5MF3TmkP7ZX14ZVHrvLD5VTmzWAWGbVFbX7 X-Received: by 10.58.107.65 with SMTP id ha1mr26184497veb.1.1399941950793; Mon, 12 May 2014 17:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.246.39 with HTTP; Mon, 12 May 2014 17:45:30 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Mon, 12 May 2014 17:45:30 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GObKZKDp-eiExbkG8WsPCbeSBes Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 00:46:00 -0000 On Mon, May 12, 2014 at 5:38 PM, Nico Williams wrote: > On Wed, Apr 16, 2014 at 8:53 AM, Tom Ritter wrote: >> ....But... There once was a thing called DNSSEC Stapled Certs >> (https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a >> SSL certificate had a chain of DNSSEC signatures in it, validating it >> via DANE (or at that time, a DANE-like mechanism.) It violates a > > I've been thinking of this for a while... > >> layering principal that people hold dearly, shoving DNS information in >> other corners it shouldn't be. But I think it would be necessary for >> the wildcard approach to be reliable for clients like browsers. > > Layers aren't pure though. Some things show through the various > layers' interfaces, sometimes several layers through. > > For example, many apps have to deal with all of DNS and TCP/IP, with > IP addresses and TCP port numbers used together in socket APIs. It > might have been a lot better if the sockets APIs had deal with > hostnames from the start, but here we are. Abstractions are leaky. > > Now in this case I think saving a client a number of DNSSEC lookups > could be convenient. We should -of course- make sure that this works > out securely -- we don't want to end up with a cache poisoning attack > here. I think that we could get a lot of mileage out of the idea of having some kind of DNSSEC-backed service binding. There are all kinds of interesting fields we could stick in there if we had such a thing and, if we do it right, clients that can't read the service binding would just fall back to normal (plaintext SNI, PKIX) TLS. I'm planning on talking about this at the meeting this week. --Andy From nobody Mon May 12 18:54:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72CA1A03AB for ; Mon, 12 May 2014 18:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcphhayY6yuH for ; Mon, 12 May 2014 18:54:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (sasl.smtp.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id F1AEC1A0387 for ; Mon, 12 May 2014 18:53:59 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 54D511510F for ; Mon, 12 May 2014 21:53:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=umtkFjuVq10H eNnXxqhDD4X7mSk=; b=XcUsSKyt6E5wpDZwQfIoKVP6T5yy/GTEedQXDE2t9ZUr vroPcs/HqYw01TP9pM6MY0WN1RZl+xjM9vvZJHrll+2SPPDKk4jbx+LHOePc+wCA 8g79c4BxFyryF2Gf4iiusUqLYqaVApWM/lBgR2EjPia4jFHERpd+3APJrWy4Ajs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=YSJNMv adeWhqkt4VlqIM+DyHlVLlucutOG+DoQsP6i/TLXHiC4yJiEFN4jTCwqQD7PaixA w70F9Rq13yPT9pI17QUpsjL8217ckGGWdqKjQNXcWFMySUBSUb9qJ94FsklVuiED CtKovwr52i2QoN8Si91Aq+nUz++AealCSA7Uo= Received: from pb-sasl0.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 4AC391510E for ; Mon, 12 May 2014 21:53:53 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl0.pobox.com (Postfix) with ESMTPSA id 7CF461510D for ; Mon, 12 May 2014 21:53:45 -0400 (EDT) Message-ID: <53717B28.9080407@pobox.com> Date: Mon, 12 May 2014 18:53:44 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Pobox-Relay-ID: 6E189CF4-DA41-11E3-A575-D2BAB895B7A1-38729857!pb-sasl0.pobox.com Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/D6enHAsl4vazug7g3_2piWIN3PQ Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 01:54:03 -0000 David Holmes wrote: > =E2=9E=A2 so a server under load can, in the initial opportunistic encr= yption phase, push back to a client and ask for a puzzle to be solved? >=20 > I was describing this idea to a colleague, and the first thing he said = was > "could you have the client mine some bitcoin for you? As a show of good= faith?" Sure! After we get rid of TLS compression, RSA key transport, non-AEAD c= iphers, and all the other crud, let's plug in Bitcoin! ;-) Mike From nobody Mon May 12 19:40:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CCE1A03BC for ; Mon, 12 May 2014 19:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isIzsRwfql7x for ; Mon, 12 May 2014 19:40:52 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8991A03B9 for ; Mon, 12 May 2014 19:40:52 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id c41so7140929yho.36 for ; Mon, 12 May 2014 19:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C0xEZISJuqqtmJdIDlYh6mhliSsm4eZBg1oiUgAADhA=; b=DwKf65lmN4NHINRMvJ/mzS66hYvug2UwKkBzPYtt/UZYrtGOL1QGYCGNgHdhiMyb1h S4uNHiIzygSaYHCxWMx2JcnN3vj6yZ3IhHw4Md7ayqJoEwTjAq5y5e1QJ5QyUNhfkwii 0FcA8oj28pWatvYL7EVewN5Rp+Z3JlvO8mUjxX4KJnyKVdm1YwfPmQknhYbd2Ag+o3Xp puMdROCCzZdb4jXSbqY8YWZxODvE8BlfxccFY7+Knu+SgI57EGiwHliXwDXr83Ky1Tp3 OGJOOfN69P2XtNo15bma3BG6YcNze3kov1YkXJOS1TQD5Bj/qNyG0pFg9XEFvPZ8Tk6N a32w== MIME-Version: 1.0 X-Received: by 10.236.84.98 with SMTP id r62mr47394747yhe.9.1399948846358; Mon, 12 May 2014 19:40:46 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 12 May 2014 19:40:46 -0700 (PDT) In-Reply-To: <53717B28.9080407@pobox.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> <53717B28.9080407@pobox.com> Date: Mon, 12 May 2014 19:40:46 -0700 Message-ID: From: Watson Ladd To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dLp3eBZWj6RoStrdRhTio-246eM Cc: TLS Mailing List Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 02:40:54 -0000 On Mon, May 12, 2014 at 6:53 PM, Michael D'Errico wro= te: > David Holmes wrote: >> >> =E2=9E=A2 so a server under load can, in the initial opportunistic encry= ption >> phase, push back to a client and ask for a puzzle to be solved? >> >> I was describing this idea to a colleague, and the first thing he said w= as >> "could you have the client mine some bitcoin for you? As a show of good >> faith?" > > > Sure! After we get rid of TLS compression, RSA key transport, non-AEAD > ciphers, > and all the other crud, let's plug in Bitcoin! ;-) We're not getting rid of these things because they are needless complexity (although they are) but because they are horrifically broken. Plugging in a puzzle consisting of doing some SHA-256 evaluations doesn't open up any holes. It seems to solve a real security issue, but might not be that effective: botnets have CPU to burn. I'm mildly for it. And if someone makes it into an altcoin somehow we might accidentally fix web micropayments. I think bigger issues are ensuring the security properties in TLS 1.3 are what we want them to be (sine qua non), making it clear what you have to implement to implement TLS, possibly letting alternatives to X509 be of equal standing, tightening up the language to make the first goal and second easier. Puzzles are a nice way to ensure DOS is hard. Sincerely, Watson Ladd > Mike > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon May 12 20:40:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295161A0821 for ; Mon, 12 May 2014 20:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGdlo4yi3m24 for ; Mon, 12 May 2014 20:40:30 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 053B21A03B5 for ; Mon, 12 May 2014 20:40:29 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so9974552vcb.15 for ; Mon, 12 May 2014 20:40:23 -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:message-id:subject :from:to:cc:content-type; bh=Pl+IWDt2F+4Y9rvDZZhWdzs6RNeFtkbQUp7mIM+7vAc=; b=Cz9f03Ym1UAfhejUS7oxxhHNpC3t5Qf6houmKnH15xUIiFdMbNedr19sQXTPNy7/N/ DkMS0RNJyAXtv7crKBbFlqlqbx0SLoRCZSctLhU78ch9ZvehqQqpiCnl5JNsSViPcaOL wiC36gomlodq4uyDrXfFnrbSSCGyVui/o73dW4wvlRRFVP6q7WG0D0hsPqqTgt9HYdN7 HZeR6J5R5bIgsxz5KQZKqKsse8uHuseqf3TuKfoX+k6tVPBzkzOT1AOvHnssdWCjbSS1 wMcuf8k7NZe11ycvIMdptV6lZT/jQae79LrUxBMtpCUahDD9Oqd4vaCWA8eZvWHCpqUL 2fqQ== MIME-Version: 1.0 X-Received: by 10.52.130.225 with SMTP id oh1mr22285143vdb.8.1399952423733; Mon, 12 May 2014 20:40:23 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.11.8 with HTTP; Mon, 12 May 2014 20:40:23 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Mon, 12 May 2014 23:40:23 -0400 X-Google-Sender-Auth: Vr0-hE_RmKrlhHTs6IfZThb-LZI Message-ID: From: Erik Nygren To: Andy Lutomirski Content-Type: multipart/alternative; boundary=bcaec520ef3beb74e004f93fd211 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ilGT2kYxNZB0tS4SGlnCwS12ycE Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 03:40:31 -0000 --bcaec520ef3beb74e004f93fd211 Content-Type: text/plain; charset=UTF-8 On Mon, May 12, 2014 at 8:45 PM, Andy Lutomirski wrote: > > I think that we could get a lot of mileage out of the idea of having > some kind of DNSSEC-backed service binding. There are all kinds of > interesting fields we could stick in there if we had such a thing and, > if we do it right, clients that can't read the service binding would > just fall back to normal (plaintext SNI, PKIX) TLS. > > I'm planning on talking about this at the meeting this week. > > --Andy > I agree that if we go down the road of wanting to encrypt the handshake that a DNS-based DNSSEC-backed service binding with plaintext SNI fallback is probably the best path. It's also on my list to discuss this week. Especially given that there's little value in encrypting SNI with encrypting/securing DNS, associating the two has some nice mutually-motivating properties. Erik --bcaec520ef3beb74e004f93fd211 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 12, 2014 at 8:45 PM, Andy Lutomirski <luto@= amacapital.net> wrote:

I think that we could get a lot of mileage out of the idea of h= aving
some kind of DNSSEC-backed service binding. =C2=A0There are all kinds of interesting fields we could stick in there if we had such a thing and,
if we do it right, clients that can't read the service binding would just fall back to normal (plaintext SNI, PKIX) TLS.

I'm planning on talking about this at the meeting this week.

--Andy

I agree that if we= go down the road of wanting to encrypt the handshake that a DNS-based DNSS= EC-backed service binding with plaintext SNI fallback is probably the best = path.=C2=A0 It's also on my list to discuss this week.=C2=A0 Especially= given that there's little value in encrypting SNI with encrypting/secu= ring DNS, associating the two has some nice mutually-motivating properties.=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik<= br>
--bcaec520ef3beb74e004f93fd211-- From nobody Tue May 13 06:07:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9A1A00BC for ; Tue, 13 May 2014 06:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdIL1G5wU28N for ; Tue, 13 May 2014 06:07:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 698FF1A00A5 for ; Tue, 13 May 2014 06:07:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 275544757B; Tue, 13 May 2014 13:07:10 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1B57147571; Tue, 13 May 2014 13:07:10 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 144D22026; Tue, 13 May 2014 13:07:10 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 13 May 2014 09:07:09 -0400 From: "Salz, Rich" To: Erik Nygren , Andy Lutomirski Date: Tue, 13 May 2014 09:07:08 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9uXRcu11yz9sANQS2p3QNgU4TOmwATvtug Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xzW4jMp4eheiCoRehvJcjg8PmkE Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 13:07:18 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgRXNwZWNpYWxseSBnaXZlbiB0aGF0IHRoZXJlJ3MgbGl0dGxlIHZhbHVlIGluIGVuY3J5cHRp bmcgU05JIHdpdGhbb3V0XSBlbmNyeXB0aW5nL3NlY3VyaW5nIEROUywgYXNzb2NpYXRpbmcgdGhl IHR3byBoYXMgc29tZSBuaWNlIG11dHVhbGx5LW1vdGl2YXRpbmcgcHJvcGVydGllcy4NClRoZSDi gJxbb3V0XeKAnSBpcyB0aGUgaW1wb3J0YW50IG1pc3NpbmcgcGFydCwgSSB0aGluay4NCkJ1dCB0 aGlzIG5vdyBiZWNvbWVzIGEgdmFyaWFudCBvZiB0aGUga2lkZGllIGdhbWU6IHlvdSBkb27igJl0 IHNob3cgbWUgeW91cnMsIEkgd29u4oCZdCBzaG93IHlvdSBtaW5lLiDimLoNCiAgICAgICAgICAg IC9yJA0KLS0NClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ2ll cywgQ2FtYnJpZGdlLCBNQQ0KSU06IHJzYWx6QGphYmJlci5tZTxtYWlsdG86cnNhbHpAamFiYmVy Lm1lPjsgVHdpdHRlcjogUmljaFNhbHoNCg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MzI1MTA0ODQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE4Mzk4ODcyNTAgLTQ2OTQ5MjgzMCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYg Y2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1s ZWZ0Oi4yNWluJz4mZ3Q7Jm5ic3A7IEVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCB0aGVyZSdzIGxpdHRs ZSB2YWx1ZSBpbiBlbmNyeXB0aW5nIFNOSSB3aXRoPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PltvdXRdPC9zcGFuPiBlbmNyeXB0aW5nL3NlY3VyaW5nIEROUywgYXNzb2NpYXRpbmcgdGhlIHR3 byBoYXMgc29tZSBuaWNlIG11dHVhbGx5LW1vdGl2YXRpbmcgcHJvcGVydGllcy48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5UaGUg 4oCcW291dF3igJ0gaXMgdGhlIGltcG9ydGFudCBtaXNzaW5nIHBhcnQsIEkgdGhpbmsuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ QnV0IHRoaXMgbm93IGJlY29tZXMgYSB2YXJpYW50IG9mIHRoZSBraWRkaWUgZ2FtZTogeW91IGRv buKAmXQgc2hvdyBtZSB5b3VycywgSSB3b27igJl0IHNob3cgeW91IG1pbmUuIDxzcGFuIHN0eWxl PSdmb250LWZhbWlseTpXaW5nZGluZ3MnPko8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAvciQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4tLcKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5QcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWth bWFpIFRlY2hub2xvZ2llcywgQ2FtYnJpZGdlLCBNQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JTTogPGEgaHJlZj0ibWFpbHRv OnJzYWx6QGphYmJlci5tZSI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPnJzYWx6QGphYmJlci5t ZTwvc3Bhbj48L2E+OyBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050USMBX1msgcorp_-- From nobody Tue May 13 09:41:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE61A010C for ; Tue, 13 May 2014 09:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8pWNrDoFgC9 for ; Tue, 13 May 2014 09:41:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C39E71A0109 for ; Tue, 13 May 2014 09:41:24 -0700 (PDT) Received: from [10.70.10.127] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C67ECF984; Tue, 13 May 2014 12:41:15 -0400 (EDT) Message-ID: <53724B21.3030605@fifthhorseman.net> Date: Tue, 13 May 2014 12:41:05 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Alyssa Rowan , tls@ietf.org References: <536A67D9.2070302@pobox.com> <536A6F8C.7020702@akr.io> In-Reply-To: <536A6F8C.7020702@akr.io> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8PASemgahmG7njHtUsoNBrxL2kQLhul2O" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qMmkVdAWNh8911DecZXyu4KQA_8 Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:41:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8PASemgahmG7njHtUsoNBrxL2kQLhul2O Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/07/2014 01:38 PM, Alyssa Rowan wrote: > For opportunistic encryption, at least with self-signed cert usage we > can then softly migrate from opportunistic to DANE-EE pinning - and > indeed that is the route SMTP has already taken, as Viktor's helpfully > highlighted. this soft migration can happen by moving from anonymous key exchanges to non-anonymous key exchanges when they publish their DANE-EE pin, though. > Meanwhile aDH denies us that option, and broadcasts our MITM > susceptibility to Mallory. I think this is more an argument that the ciphersuite negotiation shouldn't be in the clear than it is an argument to reject an aDHE key exchange scheme. I recognize that there are chicken-and-egg issues here, but it seems possible to protect the handshake itself with a non-negotiable mandatory-to-implement scheme that protects at least against passive monitoring, and then allow the rest of the communication the flexibility for algorithm agility. With proper traffic padding, this would avoid broadcasting any MITM-susceptibility to Mallory without Mallory actively making a (potentially detectable) MITM attack herself. --dkg --8PASemgahmG7njHtUsoNBrxL2kQLhul2O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTckshXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc8p4QANDbk9WznJ+mn0Pff9MBDC86 KziRYjVN2PQ0FWlmTEO5Sa/8cI1qQJzkXezUk9j87rRgub/TgTMkfvQmbitwJaM9 n1e8UpN8AN8RX9Bsl+Q8i0k8r/C18nYn3XKMkUcXgLSCocQ2SZhbq0ZiIlagi3WT XHS7RjIj/JTct3TBjwTHS4/8xhRURRx5TALctpgVNNS/++bna/a5LP9N3sSj3ZWG nfyiThbtwhMyXxjjynza6PiQQEncfsiGE/GQlRlBgPvRPBpdhNPoYk9CCmMKJK/T uzwP5P1bT5Y5SEc+btu7iA5OB9gK2rqXRnq97xWDGizGtfYvYgSs3pzkbZj4ncuY FUollNJ/rabzXon4S6P71v13NUXxHiT5FprNAAVjULyYsYDjXq1jKm6ilthKkjEt LFmGwrYJcw5+vM5XlvLys2Oau2xdIRX93IwcAT8x/IDAvOfhexa9SkRP/KWFqNOd C+jS2YeQlsPIfOgV+IgtUMaYCGC/Irojw8dIx9M8lHjUvFhRlgOfXXWmnp/L6jUj 1lFXdN03CsFR9qVoUFAKAYJXT0Kd+YgPqO1WELVmWsmURFgxjGGeu/DUsZyHfxV0 w1zM19u4MVHea24T5oqyEJtBQywcq40JLx1vjXtXUf6XTJW0e8OJwouyJRrQ7CbF zbd7fIXo6Ek2lPGD9WRw =irjO -----END PGP SIGNATURE----- --8PASemgahmG7njHtUsoNBrxL2kQLhul2O-- From nobody Tue May 13 10:54:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A9F1A0101 for ; Tue, 13 May 2014 10:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy5bL27GaMD5 for ; Tue, 13 May 2014 10:54:05 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 86BAE1A0116 for ; Tue, 13 May 2014 10:54:05 -0700 (PDT) Received: from [10.70.10.127] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 705EBF984; Tue, 13 May 2014 13:53:56 -0400 (EDT) Message-ID: <53725C34.8060105@fifthhorseman.net> Date: Tue, 13 May 2014 13:53:56 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Salz, Rich" , Erik Nygren , Andy Lutomirski References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aOGUwxLveFju13X3EAUC2APXuao1V1MH7" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Dfnyfxo6_A9h5YyGBIPUdmomu4Q Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:54:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aOGUwxLveFju13X3EAUC2APXuao1V1MH7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/13/2014 09:07 AM, Salz, Rich wrote: >> Especially given that there's little value in encrypting SNI with[out= ] encrypting/securing DNS, associating the two has some nice mutually-mot= ivating properties. > The =E2=80=9C[out]=E2=80=9D is the important missing part, I think. yes, indeed :) But that's what the dns-privacy discussion is about. https://www.ietf.org/mailman/listinfo/dns-privacy If we don't offer a standard mechanism for protecting the confidentiality of SNI (at least against passive monitors) in upcoming versions of TLS, then the dns-privacy discussion is going to have serious trouble sustaining its work by an analgous "little value unless..." argument. We shouldn't sabotage that work. The TLS WG needs to fix the SNI leak, and DNS confidentiality needs to be addressed by the DNS folks if we want to protect this information against passive eavesdropping. --dkg --aOGUwxLveFju13X3EAUC2APXuao1V1MH7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTclw0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcaAAP/2pk68qw/c9tIua5xjOmpy4K Dlf3yPcSOJ5lFlHq/4KRNyGKZXZTU/aRqkDNnTnEic2u3U8V20bU2JogeTm9p1Vu 34mabjqT+EYz+S04lTm5umIeQJXMfNhD66DQ89CR+NC7mcridf5uJ6SgCU+w5X32 SHI/53fx4KiGNZd7n9UKVUa68RKFSdZmkBCIK9j6RVSEu0znidP2KjfXhZMxPWQk ofA1K2sam7GckaYrqpnbUKhZ/TjMeO3GNaKhdD3IoBCG1KVj34TlGBahcjB//NH9 f9Y+ic/p36uOYBEB2R0DIvyJCsJfGRUYesuQi4kptAIneztHric1JBjAHCWQJW45 LhO1C1POoak1/5j9ZEO6EUYVaJxCo3JmKgwvew/xUSm3+mrum2ykPT2mn88Vm/9h cn7wo92niHiAv6KBPV7iiEY+cIkv8GuwRXPu7HQcoj8rGTmjzmgNGVCM9UWEmJHq FjwCe5r/jFe3xjk/0ktAZ8xDSvV8mA08+ZqrqlTilvjb3BeGTvNW0ArV7AQJmHgd kE5HgITHqS8L+Vnk9FrTejStK/EEGuk0Nx4af8CDhU8c5rwy99RN13d34Fgjg24y ajc2Zy0wIpA4apDmwHakX6yc8VEVORonbkFO7uMiPg9qoyZhKi7PZ2LGAhsrt2uL NFEFY+BkGp8031fKOxZp =rzMQ -----END PGP SIGNATURE----- --aOGUwxLveFju13X3EAUC2APXuao1V1MH7-- From nobody Tue May 13 10:56:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572561A011A for ; Tue, 13 May 2014 10:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-jflv8wMn-K for ; Tue, 13 May 2014 10:56:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id B80881A0160 for ; Tue, 13 May 2014 10:56:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 30DA5475F5; Tue, 13 May 2014 17:56:17 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1B864475EA; Tue, 13 May 2014 17:56:17 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 1821D80040; Tue, 13 May 2014 17:56:17 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 13 May 2014 13:56:16 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , Erik Nygren , Andy Lutomirski Date: Tue, 13 May 2014 13:56:15 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9u1Fhqg/nZx71GR2+ihfl84861aAAABLJg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA266@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> In-Reply-To: <53725C34.8060105@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IZ5w5uGbkxzYyM4M7RLsNkWa79k Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:56:25 -0000 PiBUaGUgVExTIFdHIG5lZWRzIHRvIGZpeCB0aGUgU05JIGxlYWssIGFuZCBETlMgY29uZmlkZW50 aWFsaXR5IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBieSB0aGUgRE5TIGZvbGtzIGlmIHdlIHdhbnQg dG8gcHJvdGVjdCB0aGlzIGluZm9ybWF0aW9uIGFnYWluc3QgcGFzc2l2ZSBlYXZlc2Ryb3BwaW5n Lg0KDQpJJ3ZlIGFscmVhZHkgd3JpdHRlbiB3aHkgSSB0aGluayBlbmNyeXB0aW5nIFNOSSBpcyBu b3Qgd29ydGggdGhlIHRyYWRlLW9mZnMuICBZb2F2LCBJIHRoaW5rLCBhZGRlZCB0aGUgcG9pbnQg dGhhdCB0aGUgdHJhZmZpYyBhbmFseXNpcyB3aWxsIGdpdmUgaXQgYXdheSwgYW55d2F5Lg0KDQpJ dCBodXJ0cyBtb3JlIHRoYW4gaXQgaGVscHMuDQoNCgkvciQNCg0KLS0gIA0KUHJpbmNpcGFsIFNl Y3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJTTog cnNhbHpAamFiYmVyLm1lOyBUd2l0dGVyOiBSaWNoU2Fseg0K From nobody Tue May 13 11:21:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52E11A01CA for ; Tue, 13 May 2014 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DIdf53cSfD0 for ; Tue, 13 May 2014 11:21:00 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7352C1A01C9 for ; Tue, 13 May 2014 11:21:00 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id lh14so984022vcb.19 for ; Tue, 13 May 2014 11:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gq9wK2g/IhOkewQsBP1IzTJQifqpRzr/2i5XKVA102w=; b=haeEI+R8j/TbxvGGxN5dgJVQp3iEpGuMfNPc7f7Us6Wy29S7dNMJJioU4hGWbzjhF/ QKcrVEuDh+ImLYWtsQSvGNq3AEFgKbkQtSRmPVDkT+DI6vZqqakwnBsOHHnENHm3JgAs eeA+CsFSSm/lPIUJGyqGcixLuiWWQPVAn53UpSeM7ERMznARwJy7So9T+euEqaFSGQQM cOBbod+Dvh9+678ydkOMt6BP6WZ0HR030+OiSJBRLnuoCHFf6wpIjSDsaosh/Ae7DhmM oMnl9d1GyKFVFQXbqTArGAT3MwTtfcNouj8FGQTnVaJubf9jDrrWdb36YCZd9O755LOC gO3w== MIME-Version: 1.0 X-Received: by 10.58.126.4 with SMTP id mu4mr31012236veb.0.1400005253937; Tue, 13 May 2014 11:20:53 -0700 (PDT) Received: by 10.220.78.74 with HTTP; Tue, 13 May 2014 11:20:53 -0700 (PDT) In-Reply-To: <0A5F4392-1553-4F7E-BD72-D1F44B8E83A3@gmail.com> References: <20140512210747.10675.45300.idtracker@ietfa.amsl.com> <53713CDE.1070308@cs.tcd.ie> <0A5F4392-1553-4F7E-BD72-D1F44B8E83A3@gmail.com> Date: Tue, 13 May 2014 22:20:53 +0400 Message-ID: From: Mohamad Badra To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b6700afd840bb04f94c1ff2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SWvowhwDjDaS31rpXmiJzY33zJE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] IPR Disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 18:21:04 -0000 --047d7b6700afd840bb04f94c1ff2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 13, 2014 at 2:19 AM, Yoav Nir wrote: > > On May 13, 2014, at 12:27 AM, Stephen Farrell > wrote: > > After the draft was placed in the RFC editor's queue we got > > a heads-up that this might be coming so I asked the RFC editor > > to hold publication for a bit hoping we'd find out more which > > we now have. > > > > So if the WG wanted to make some change to the document, > > that is still possible. If the WG are happy to go ahead then > > I can ask the RFC editor to proceed as normal. > > IANAL, but that patent seems to be about multiplexing multiple > applications within a single session, so more like SSL-VPN than just TLS. > In fact the patent talks about VPNs in the description part. > > More specifically, all the application negotiation in the patent happens > in application data records, not handshake records. So it's multiplexing at > the application layer, vs selection at the handshake. Doesn't seem to me > that it applies. > > The application negotiation is done by using a TLS extension, in which the client send a list of application names and the server replies with the selected application (See Fig. 2 in the patent and the description text [0022]). Best regards, Badra --047d7b6700afd840bb04f94c1ff2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, May 13, 2014 at 2:19 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On May 13, 2014, at 12:27 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: 
> After the draft was placed in the RFC editor's queue we got
> a heads-up that this might be coming so I asked the RFC editor
> to hold publication for a bit hoping we'd find out more which
> we now have.
>
> So if the WG wanted to make some change to the document,
> that is still possible. If the WG are happy to go ahead then
> I can ask the RFC editor to proceed as normal.

IANAL, but that patent seems to be about multiplexing multiple applic= ations within a single session, so more like SSL-VPN than just TLS. In fact= the patent talks about VPNs in the description part.

More specifically, all the application negotiation in the patent happens in= application data records, not handshake records. So it’s multiplexin= g at the application layer, vs selection at the handshake. Doesn’t se= em to me that it applies.


The application negotiation is done by= using a TLS extension, in which the client send a list of application name= s and the server replies with the selected application (See Fig. 2 in the p= atent and the description text [0022]).
Best regards,
Badra
--047d7b6700afd840bb04f94c1ff2-- From nobody Tue May 13 12:58:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861B81A01F0 for ; Tue, 13 May 2014 12:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGA6wtrKXk4B for ; Tue, 13 May 2014 12:58:00 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBFC1A01ED for ; Tue, 13 May 2014 12:57:59 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so1159270qcr.20 for ; Tue, 13 May 2014 12:57:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VsjReWZva+npSH+pzHnWUFLeTk+DoJDeZdRrDBCN6FQ=; b=MgkfIO1O91vXI1/kTPgaVGrAGVQbRnndrbuTWCTt5XQgRImHXhTnSebLxPq3t5x4pu b5SoWOwsuXDZJVZbcF50cai72bXlMuw+au9zfnB4L6CBBLX/2DCvtlSs1u+y8KBJbsLZ EO51ryKmLlEmzUz0/rrLFzkPq3tr/EJSAjEE1FvbtdBaLj1nJAuKqGhFrnaIDF4l3TkH lAwgpcRzrKGDldsGQTdeWUSXC2URY06thG/VpPVU7I2b0kETQG3cTipyQca2jFDbPljb o0e842tahf4Ipc5cGn5qziEbHdC3MqYRVkR8/gAwfQBgE8wP6kwbJRr7LwE51wn+lhcY jIQw== X-Gm-Message-State: ALoCoQl7/zSyKihawRGxIV7WTDbQN0b/0hzbMYIcQi4c8lCQjTSu2P4ptGfjrmU7uMBuvNzG6LbW X-Received: by 10.140.34.228 with SMTP id l91mr49451103qgl.85.1400011073377; Tue, 13 May 2014 12:57:53 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id i3sm12572892qgf.14.2014.05.13.12.57.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 12:57:51 -0700 (PDT) Message-ID: <53727940.2070900@nthpermutation.com> Date: Tue, 13 May 2014 15:57:52 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> In-Reply-To: <53725C34.8060105@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W-CXV9uqwjWc-lt2nS5J_tCvNck Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 19:58:01 -0000 On 5/13/2014 1:53 PM, Daniel Kahn Gillmor wrote: > y If we don't offer a standard mechanism for protecting the > confidentiality of SNI (at least against passive monitors) in upcoming > versions of TLS, then the dns-privacy discussion is going to have > serious trouble sustaining its work by an analgous "little value > unless..." argument. We shouldn't sabotage that work. The TLS WG needs > to fix the SNI leak, and DNS confidentiality needs to be addressed by > the DNS folks if we want to protect this information against passive > eavesdropping. --dkg One of the things missing from this discussion is whether or not encrypting the SNI is sufficiently resistant to traffic analysis techniques to make it worthwhile: E.g. A trivial attack is where there are a 100 web sites at a particular IP address, but only one of them has a name that is 28 characters in length and that's the one eavesdroppers care about. A non trivial attack is where the web sites can be characterized via their patterns of traffic (a web page with 28 items, of which 16 are pictures with known fixed lengths). Random padding can mitigate some of this (but will require some changes to TLS) and random reordering of HTTP requests can also help a bit (mostly a client side change), but transaction based protocols like HTTP (e.g. most of the time I'm pretty sure that the client is sending some sort of GET even if I don't know exactly what its asking for) tend to reveal the underlying patterns, even if the actual data is protected. Mike From nobody Tue May 13 13:20:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00E1A01EF for ; Tue, 13 May 2014 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk_gqJjm1-G3 for ; Tue, 13 May 2014 13:20:39 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 389161A01BA for ; Tue, 13 May 2014 13:20:25 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 766C52007F222 for ; Tue, 13 May 2014 13:20:18 -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=nvnssUopA4+vxTPJ6Oxr PpxjVqU=; b=mjDHbaw6vgfCRoRUQQ5kCUe/Ak1ZWrlnLI6ohEkRz3Et01l4+J4E gKZleGX4VZ9qiGp0WjwApBUJyRFxGndgak25IIOtVKVbRE6NhGHS4rMzGYESau0X k4LMba026ca4WEQG7sGR721rXQrOjEX2hE/MDdGpT2L6yX+0P06g+pM= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 2BA232007F21C for ; Tue, 13 May 2014 13:20:18 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so935385wgg.30 for ; Tue, 13 May 2014 13:20:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.84.101 with SMTP id x5mr4952134wjy.52.1400012417009; Tue, 13 May 2014 13:20:17 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 13 May 2014 13:20:16 -0700 (PDT) In-Reply-To: <53727940.2070900@nthpermutation.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <53727940.2070900@nthpermutation.com> Date: Tue, 13 May 2014 15:20:16 -0500 Message-ID: From: Nico Williams To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SEzcLh-wEAf_vvtnVt0fGPAMVrY Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 20:20:41 -0000 On Tue, May 13, 2014 at 2:57 PM, Michael StJohns wrote: > On 5/13/2014 1:53 PM, Daniel Kahn Gillmor wrote: > One of the things missing from this discussion is whether or not encrypting > the SNI is sufficiently resistant to traffic analysis techniques to make it > worthwhile: E.g. A trivial attack is where there are a 100 web sites at a > particular IP address, but only one of them has a name that is 28 characters > in length and that's the one eavesdroppers care about. A non trivial attack > is where the web sites can be characterized via their patterns of traffic (a > web page with 28 items, of which 16 are pictures with known fixed lengths). Well, and for the many cases where there are many fewer than 100 sites at one IP address... the IP address will reveal plenty. > Random padding can mitigate some of this (but will require some changes to > TLS) and random reordering of HTTP requests can also help a bit (mostly a > client side change), but transaction based protocols like HTTP (e.g. most of > the time I'm pretty sure that the client is sending some sort of GET even if > I don't know exactly what its asking for) tend to reveal the underlying > patterns, even if the actual data is protected. HTTP has infinitely extensible headers just for this purpose ;) We can address some of the traffic analysis problems. I think if we don't now, we will eventually. It's just a question of when. Sooner would be better. It might not be feasible at this time; we should find out if it is. So far it looks like we'd need: a) confidentiality protection in DNS, b) leverage DNSSEC/DANE to get zero-round-trip SNI encryption in TLS, c) apply care to avoid leaking information via payload sizes. What else? Sounds like a lot to get right for 1.3! Even if we defer (a) but make some assumptions about it so we can ship 1.3 and enable (a) later, we might get it wrong. Nico -- From nobody Tue May 13 14:15:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234291A01FE for ; Tue, 13 May 2014 14:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_b_g6zRuxQj for ; Tue, 13 May 2014 14:15:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 488461A01C9 for ; Tue, 13 May 2014 14:15:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7141EBE6F; Tue, 13 May 2014 22:15:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLMXEgIU3jxG; Tue, 13 May 2014 22:15:37 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.28.248]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7A39BE80; Tue, 13 May 2014 22:15:36 +0100 (IST) Message-ID: <53728B78.30306@cs.tcd.ie> Date: Tue, 13 May 2014 22:15:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Nico Williams , Michael StJohns References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <53727940.2070900@nthpermutation.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zuNzNGm3hOl88jmoiNGocJ34Cl0 Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 21:15:47 -0000 Hiya, Just some thoughts on this... no hats and all that. On 13/05/14 21:20, Nico Williams wrote: > HTTP has infinitely extensible headers just for this purpose ;) HTTP/2.0 is also adding padding, so it could be that a good solution here for web sites depends on some or all of TLS1.3 and HTTP/2.0 and DNS-priv. That is quite a lot of moving parts, but if we don't fully examine the SNI part of that story now, then I can't see it happening again for a long time to be honest. I also don't like the "DNS is clear, so why not SNI" argument. Because that goes on to "if SNI is clear, then why not ALPN?" And if ALPN, then why not the server cert? Etc. etc. And then in the end we lose out on lots of chances to counter traffic analysis. (Not that we know so well how to do that, but nonetheless...) If the argument ends up being that nobody wants to implement SNI encryption, then that's important, but I don't believe we have a proposal so far that'd allow folks to decide that. (Or maybe I missed it, I just saw some sketches in mails.) That does however put the onus on those who would like to see this done to write down how. If nobody does that, then I'd say Rich's argument will win by default since he's pointing out a real difficulty. I think that'd be a pity but doing better depends on those who want to do better figuring out and writing down how. One other thought, maybe more optimistic: could it be that there might be ways to protect things like SNI used for routing the 2nd and later times you visit a web site, even if TLS had to put the DNS name in clear (or close-to) first time around? If one gets that property via some mechanism or other, and if the hosts at which there's any point in trying to hide SNI (those with lots of VirtualHost equivalents) get lots of non-first time visits maybe even from the same clients, and if DNS-priv happened, then maybe that'd be a sufficiently useful answer. I'm not sure, but that's the kind of analysis that needs to be done by someone interested in countering traffic analysis. I really hope someone's up for doing that kind of work. S. From nobody Tue May 13 19:20:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FBD1A01F9 for ; Tue, 13 May 2014 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPTLaNhLkM4L for ; Tue, 13 May 2014 19:20:21 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F00491A01E8 for ; Tue, 13 May 2014 19:20:20 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4E2K7Q4003488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 04:20:07 +0200 (MEST) In-Reply-To: <53728B78.30306@cs.tcd.ie> To: Stephen Farrell Date: Wed, 14 May 2014 04:20:07 +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: <20140514022007.5C7FD1AD07@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GYk94oKRVttAA3ZhWfn8xC7UNYE Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 02:20:23 -0000 Stephen Farrell wrote: > > One other thought, maybe more optimistic: could it be that > there might be ways to protect things like SNI used for > routing the 2nd and later times you visit a web site, even > if TLS had to put the DNS name in clear (or close-to) first > time around? The latter looks like a contradiction to SNI being used for routing to me. When SNI is used for routing, then it MUST be present on the initial ClientHello on every new connection, or routing (to other than the default credential) will be impossible. It doesn't really matter whether that routing is physical (to a different backend server) or just logical (to a different server credential on the same host. The session_id that is normally used for the abbreviated handshake is no suitable substitute here. These sessions may expire quickly and randomly (like depending on server load and cache contention), within a few minutes, and the session cache is not necessarily shared among TLS clients or among TLS servers involved in the communication. E.g. a while ago I observed an unfavorable behaviour of a browser on a platform after an OS minor version upgrade with respect to browser plugins. The OS upgrade seems to have seperated the browser's TLS session cache from the TLS session cache used by the plugins, and the plugins were not prepared to do their own promptin "server cert warning--do you want to continue anyway", but instead just silently failed (resulting in a blank/white area where the plugin should have rendered the contents). Hiding the server hostname by encrypting SNI looks extremely silly for anything that operates like a web browser. Those beasts spill HTTP-Referers all over the place, keep bookmarks, keep histories, keep cookies and do lots of other stuff to spread hostnames from URLs all over the place. The hostname horse has left the barn 25 years ago. Closing the barn door today is going to be futile. IF you have anything to hide, then you MUST ensure, that it is not vitally dependend on the hostname of the server remaining secret. I do not believe that it would be a good idea to create the provably false impression that TLS is a panacea and hiding of SNI would provide any security or any privacy benefit vaguely similar to characteristics that TOR tries to provide -- because it doesn't, and can't. -Martin From nobody Tue May 13 19:22:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D001A01F8 for ; Tue, 13 May 2014 19:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5-7QUucA6ri for ; Tue, 13 May 2014 19:22:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C50421A01E8 for ; Tue, 13 May 2014 19:22:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3CF2B2AAD62; Wed, 14 May 2014 02:22:22 +0000 (UTC) Date: Wed, 14 May 2014 02:22:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140514022221.GE27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> <20140507055835.GN27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140507055835.GN27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Hk8cZvHAnwOcrO464VWidb4qnc Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 02:22:32 -0000 On Wed, May 07, 2014 at 05:58:35AM +0000, Viktor Dukhovni wrote: > > Ask someone "When you send email to someone, who can > > read it?". > > We're talking about TLS in SMTP not who can or can't read stored > email. Whether the man in the street knows it or not, a substantial > fraction (estimated 20% and growing) of email traffic is encrypted > in transit, just because both ends can simply turn on STARTTLS. > I bet this fraction is larger than the fraction of HTTP traffic > that is protected inside HTTPS. Right on queue: https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223 I was fairly sure my number of 20% was conservative, now Facebook measures it at 58%: We found that 76% of unique MX hostnames that receive our emails support STARTTLS. As a result, 58% of notification emails are successfully encrypted. Additionally, certificate validation passes for about half of the encrypted email, and the other half is opportunistically encrypted. 74% of hosts that support STARTTLS also provide Perfect Forward Secrecy. It is perhaps time to retire the belief that TLS for email is in a "sad state". Of course it would be nice to also have authentication, but for that we need DNSSEC deployment and publication of TLSA RRs. An ISP (posteo.de) deployed the first email transport authentication "fax-machine" this week: http://www.heise.de/newsticker/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html they can now deliver email securely to debian.org, and any day now ietf.org, plus a smattering of smaller domains operated by individual DANE early adopters (welcome to the club Alyssa). -- Viktor. From nobody Tue May 13 19:49:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA09C1A021B for ; Tue, 13 May 2014 19:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUiwHWbd0ZCG for ; Tue, 13 May 2014 19:49:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDC91A0212 for ; Tue, 13 May 2014 19:49:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0D5BA2AAD62; Wed, 14 May 2014 02:49:14 +0000 (UTC) Date: Wed, 14 May 2014 02:49:13 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140514024913.GF27883@mournblade.imrryr.org> References: <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> <20140507055835.GN27883@mournblade.imrryr.org> <20140514022221.GE27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140514022221.GE27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yLVw-mazMnlofd11u86YA0eZCkA Subject: Re: [TLS] The risk of misconfiguration (Muphry's law) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 02:49:22 -0000 On Wed, May 14, 2014 at 02:22:21AM +0000, Viktor Dukhovni wrote: > Right on queue: s/queue/cue/ Too much time spent hacking email, fingers automatically type "queue". -- Viktor. From nobody Tue May 13 20:06:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24F71A0228 for ; Tue, 13 May 2014 20:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sqSoYCiQoN0 for ; Tue, 13 May 2014 20:06:15 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2821A0231 for ; Tue, 13 May 2014 20:06:15 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id q9so1086894ykb.25 for ; Tue, 13 May 2014 20:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AmfVkVDWySuljvMZL7F2u8zhF2MbWjx3wap++HoNC6Y=; b=t0TNQPEbpNU43M4H2sm5BxGcd547AScwJ8JWAEtiH8D0+vv/OIXerCO6QTvUTz9gRW QC1zE/YhoB9B7QRVk9Xeu3fBdjqdM6ByCovRvMISl1+dlnIsWxEmLuQTPY50t7KMnhnD eY6yhs6X7T4jnOvhvbTYCEQLv76fREDHTssphIEYqDJIyC9CJcT5qEHDBz+NDk5Fs+x/ h6/NUDZEsLitlSClZknUGIRKYewnUHQ81P6tvmbJ/7QiDV4U+2Xwy5RoNLanhmp7Zeul o8W2tSBZBnvEBAuo9dgWdtHJi41tfLfMSvWWmfnvujJ3IuNSKVFBGzqE9nZBhJCSvqqM zH3A== MIME-Version: 1.0 X-Received: by 10.236.88.193 with SMTP id a41mr1335632yhf.22.1400036768746; Tue, 13 May 2014 20:06:08 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 13 May 2014 20:06:08 -0700 (PDT) In-Reply-To: <20140514022221.GE27883@mournblade.imrryr.org> References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> <20140507055835.GN27883@mournblade.imrryr.org> <20140514022221.GE27883@mournblade.imrryr.org> Date: Tue, 13 May 2014 20:06:08 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wLOISQlb31CVOMRnliCBpFYSJtQ Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 03:06:22 -0000 On Tue, May 13, 2014 at 7:22 PM, Viktor Dukhovni wrote: > On Wed, May 07, 2014 at 05:58:35AM +0000, Viktor Dukhovni wrote: > >> > Ask someone "When you send email to someone, who can >> > read it?". >> >> We're talking about TLS in SMTP not who can or can't read stored >> email. Whether the man in the street knows it or not, a substantial >> fraction (estimated 20% and growing) of email traffic is encrypted >> in transit, just because both ends can simply turn on STARTTLS. >> I bet this fraction is larger than the fraction of HTTP traffic >> that is protected inside HTTPS. > > Right on queue: > > https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223 > > I was fairly sure my number of 20% was conservative, now Facebook > measures it at 58%: > > We found that 76% of unique MX hostnames that receive our emails > support STARTTLS. As a result, 58% of notification emails are > successfully encrypted. Additionally, certificate validation > passes for about half of the encrypted email, and the other > half is opportunistically encrypted. 74% of hosts that support > STARTTLS also provide Perfect Forward Secrecy. > > It is perhaps time to retire the belief that TLS for email is in > a "sad state". Of course it would be nice to also have authentication, > but for that we need DNSSEC deployment and publication of TLSA RRs. So 0% of the email is actually protected from being read by anyone on the network. (well, modulo PGP). In another 20 years we might have a solution deployed. And for this you want to run the risk of using aDH? Sincerely, Watson Ladd From nobody Wed May 14 00:45:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9171A0276 for ; Wed, 14 May 2014 00:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMrnv8txewCf for ; Wed, 14 May 2014 00:45:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC901A0273 for ; Wed, 14 May 2014 00:45:11 -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 s4E7j0Vg015875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 03:45:00 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4E7iv4U031772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 May 2014 03:44:59 -0400 Message-ID: <1400053497.2757.12.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Daniel Kahn Gillmor Date: Wed, 14 May 2014 09:44:57 +0200 In-Reply-To: <53725C34.8060105@fifthhorseman.net> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BxLko0Hofa0UOfia5vjr-m7eqkk Cc: Andy Lutomirski , "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 07:45:13 -0000 On Tue, 2014-05-13 at 13:53 -0400, Daniel Kahn Gillmor wrote: > On 05/13/2014 09:07 AM, Salz, Rich wrote: > >> Especially given that there's little value in encrypting SNI with[out] encrypting/securing DNS, associating the two has some nice mutually-motivating properties. > > The “[out]” is the important missing part, I think. > yes, indeed :) But that's what the dns-privacy discussion is about. > > https://www.ietf.org/mailman/listinfo/dns-privacy > If we don't offer a standard mechanism for protecting the > confidentiality of SNI (at least against passive monitors) in upcoming > versions of TLS, then the dns-privacy discussion is going to have > serious trouble sustaining its work by an analgous "little value > unless..." argument. We shouldn't sabotage that work. > The TLS WG needs to fix the SNI leak, and DNS confidentiality needs to > be addressed by the DNS folks if we want to protect this information > against passive eavesdropping. Fixing the SNI leak is easy, just don't use SNI. The main issue is in the TLS handshake which sends the certificates in plain. A fix for passive eavesdroppers would require a new IPSec-style handshake. It comes at a cost though. Load balancers and redirectors will need to terminate TLS in order to redirect the traffic to the proper host. Terminating TLS there would mean (a) the encrypted session isn't terminated on the intended server but somewhere else, (b) user authentication with TLS will be pretty much unusable for hosts behind that type of systems, (c) software redirection of sessions (e.g., because a different process handles a different host or protocol - see ALPN) will also become very difficult. regards, Nikos From nobody Wed May 14 03:01:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06591A0299 for ; Wed, 14 May 2014 03:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgl2A5ez4L_O for ; Wed, 14 May 2014 03:01:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EECB91A0286 for ; Wed, 14 May 2014 03:01:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 252D3BE6E; Wed, 14 May 2014 11:01:35 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyHGxA9Tf8mV; Wed, 14 May 2014 11:01:35 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07FA5BE63; Wed, 14 May 2014 11:01:35 +0100 (IST) Message-ID: <53733EFF.4010000@cs.tcd.ie> Date: Wed, 14 May 2014 11:01:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <53692FC2.1060009@akr.io> <20140506221344.GB27883@mournblade.imrryr.org> <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> <20140507055835.GN27883@mournblade.imrryr.org> <20140514022221.GE27883@mournblade.imrryr.org> In-Reply-To: <20140514022221.GE27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/svBskV1RaBZkm0hZkV-BytaSRRA Cc: "Murray S. Kucherawy" Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:01:47 -0000 Good stuff. And thanks to FB for measuring and making this public, be great if they wanted to do this now and then to see how what trends emerge and/or if others did similarly. S. On 14/05/14 03:22, Viktor Dukhovni wrote: > On Wed, May 07, 2014 at 05:58:35AM +0000, Viktor Dukhovni wrote: > >>> Ask someone "When you send email to someone, who can >>> read it?". >> >> We're talking about TLS in SMTP not who can or can't read stored >> email. Whether the man in the street knows it or not, a substantial >> fraction (estimated 20% and growing) of email traffic is encrypted >> in transit, just because both ends can simply turn on STARTTLS. >> I bet this fraction is larger than the fraction of HTTP traffic >> that is protected inside HTTPS. > > Right on queue: > > https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223 > > I was fairly sure my number of 20% was conservative, now Facebook > measures it at 58%: > > We found that 76% of unique MX hostnames that receive our emails > support STARTTLS. As a result, 58% of notification emails are > successfully encrypted. Additionally, certificate validation > passes for about half of the encrypted email, and the other > half is opportunistically encrypted. 74% of hosts that support > STARTTLS also provide Perfect Forward Secrecy. > > It is perhaps time to retire the belief that TLS for email is in > a "sad state". Of course it would be nice to also have authentication, > but for that we need DNSSEC deployment and publication of TLSA RRs. > > An ISP (posteo.de) deployed the first email transport authentication > "fax-machine" this week: > > http://www.heise.de/newsticker/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html > > they can now deliver email securely to debian.org, and any day now > ietf.org, plus a smattering of smaller domains operated by individual > DANE early adopters (welcome to the club Alyssa). > From nobody Wed May 14 07:32:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C5D1A00B8 for ; Wed, 14 May 2014 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZzmnmNYZkX5 for ; Wed, 14 May 2014 07:32:29 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18E1A02B4 for ; Wed, 14 May 2014 07:32:26 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so2511755wib.0 for ; Wed, 14 May 2014 07:32:19 -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:content-type; bh=oCsBA7kqUvsrbG9vPajByG99jztd5Eo18JliXTmEGJM=; b=G+hgwTAmk2IK3Aex9a2q+SCaZFi7YItOB30VwMNr/fmVQneS6ktT1AKNbqhaxGGHGP RUD1k/F0IZpZOz7ptAbiLtZypY7GvlK3hIsmh+meTwStBHPo+YYfi1YEzF4aZDjd0xos dH0k6AU/cSIGeCFfkFOsa5qnwyLcew4fNOInoBcD9WfrLctSc9M2UPlx5IxJkAVaKfwp MV2D0+5ibieoa+4YK6A5cCFzgKzowYVDdfv3pRqAntlsZNc0aoYIcrrce9W3TTgZiIEH eaf4or+RKax3nLAyQZuml6fXtrM63Xzjg4uhZQ0oTvCrlTEAsVunf2GRZNvPYVbdQ4aX 8nrQ== MIME-Version: 1.0 X-Received: by 10.180.108.242 with SMTP id hn18mr3842335wib.34.1400077938956; Wed, 14 May 2014 07:32:18 -0700 (PDT) Received: by 10.194.157.9 with HTTP; Wed, 14 May 2014 07:32:18 -0700 (PDT) Date: Wed, 14 May 2014 10:32:18 -0400 Message-ID: From: Phillip Hallam-Baker To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mEILB9P17PRrsYhmiGL1Iv3me5Q Subject: [TLS] SNI and DNS Resolver Privacy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 14:32:36 -0000 We have lots of talk about TLS and DNS leaking privacy sensitive information. These are obviously linked in that there is little point in protecting DNS if the subsequent conversation to the endpoint is en-clair. And SNI leakage is likely to undo any DNS security scheme. I have a mechanism that can protect SNI but it is predicated on a DNS privacy solution. So we solve that first and then use the solution to attack the SNI issue. In my approach to DNS privacy I am most concerned about the client-resolver link. My approach can be applied in the resolver-authoritative link but it needs to compliment other approaches such as label minimization etc. Premise 1: The DNS resolver is a trusted service. At minimum the service is trusted to protect the confidentiality of the queries it makes. In most cases the resolver is also trusted to return data to the client if it exists (and this is desirable). The degree of trust may be higher, especially if the DNS resolver is being run by the party relying on it. Premise 2: Since SNI privacy is essentially an extension of the DNS privacy concerns it is logical that a service trustworthy for one is trustworthy for the other. Conclusion: A DNS resolver is an appropriate entity to broker credentials to encrypt the TLS handshake including SNI. My Private DNS approach is built on two main building blocks. The first is a key exchange service. This is currently built on top of TLS http://tools.ietf.org/html/draft-hallambaker-wsconnect-07 The connection protocol itself isn't very important here. The important part is the output of this exchange is: * A shared secret * A set of cryptographic parameters * An opaque secret identifier which may contain the above information plus encrypted account information to allow a kerberos-style stateless server to use the token for encryption. Once we have such a token, Private-DNS is straightforward. The whole draft is only 15 pages, most of which are examples: http://tools.ietf.org/html/draft-hallambaker-privatedns-00 Now let us consider the TLS case and let us further consider a situation in which the Authoritative DNS server for the TLS server supports the Private DNS protocol and the resolver has established a ticket with that server. In this situation we have all the ingredients to deploy a full Kerberos-style solution. We might want to introduce a ticket-granting-ticket type concept but even that isn't essential unless traffic analysis is a big concern. At this point we can use the Kerberos* trust framework established in the tickets for a variety of purposes: 1) Encrypt the TLS handshake 2) Pre-empt some or all of the handshake. 3) Skip TLS entirely and just encrypt and authenticate the transport under the ticket mediated key. Call this protocol UYFM (its probably not the acronym you are thinking of) Note 1: Although we are encrypting the session, the trust context is not end-to end. There are four parties that know secrets that are sufficient to decrypt or spoof the traffic. So this would not be an alternative to TLS for online commerce or banking and it would be a lousy approach to password security. This is not going to be as robust as TLS. It is however going to be vastly superior to raw IP. This approach would be a very good one for an objective of eliminating plaintext traffic. So it would be good for the SNI and handshake part of TLS. Note 2: To apply the protocol in practice we would need to have a management protocol that allows the TLS server and DNS server to communicate. But this is a critical need in any case. Note 3: To enable the introduction of the protocol we would need to either publish the necessary data in the DNS or jack up the level of abstraction a notch as I propose in Omnibroker. * We can use Kerberos tickets but it is not necessary for any party to know the internal structure of a ticket other than the party who created the ticket except in the case of ticket granting tickets. -- Website: http://hallambaker.com/ From nobody Wed May 14 08:13:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACED1A02B9 for ; Wed, 14 May 2014 08:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMnwsne5eRIF for ; Wed, 14 May 2014 08:13:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id EBBBC1A02B4 for ; Wed, 14 May 2014 08:13:41 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0CD0116559E; Wed, 14 May 2014 15:13:35 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 01A5716553C; Wed, 14 May 2014 15:13:35 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id DD4E29804E; Wed, 14 May 2014 15:13:34 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 14 May 2014 11:13:34 -0400 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , Daniel Kahn Gillmor Date: Wed, 14 May 2014 11:13:33 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9vSGw0qd60vJDYSuKslgo6Y7tbZAAPm3Ng Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA62A@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <1400053497.2757.12.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1400053497.2757.12.camel@dhcp-2-127.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7VHTRZYt6ADCgWc17JY-Jt9glZI Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:13:43 -0000 PiAgTG9hZCBiYWxhbmNlcnMgYW5kIHJlZGlyZWN0b3JzIHdpbGwgbmVlZCB0byB0ZXJtaW5hdGUg VExTIGluIG9yZGVyIHRvIHJlZGlyZWN0IHRoZSB0cmFmZmljIHRvIHRoZSBwcm9wZXIgaG9zdC4N Cg0KV2hpY2ggd2Uga25vdyBoYXZlIGJlZW4gaW50ZXJkaWN0ZWQgYnkgdmFyaW91cyBuYXRpb25h bCBzZWN1cml0eSBhZHZlcnNhcmllcy4NCg0KCS9yJA0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJp dHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwgTUENCklNOiByc2Fs ekBqYWJiZXIubWU7IFR3aXR0ZXI6IFJpY2hTYWx6DQo= From nobody Wed May 14 08:25:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231281A00B8 for ; Wed, 14 May 2014 08:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKq8CF65cbkC for ; Wed, 14 May 2014 08:25:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F04871A008F for ; Wed, 14 May 2014 08:25:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC86DBE63; Wed, 14 May 2014 16:25:47 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6ba0PB5KpVz; Wed, 14 May 2014 16:25:47 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88934BE56; Wed, 14 May 2014 16:25:47 +0100 (IST) Message-ID: <53738AFC.4060904@cs.tcd.ie> Date: Wed, 14 May 2014 16:25:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Salz, Rich" , Nikos Mavrogiannopoulos , Daniel Kahn Gillmor References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <1400053497.2757.12.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA62A@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA62A@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5Yd5FkyJ3TofKi2YfpXuU6WY0Cc Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:25:57 -0000 On 14/05/14 16:13, Salz, Rich wrote: >> Load balancers and redirectors will need to terminate TLS in order >> to redirect the traffic to the proper host. > > Which we know have been interdicted by various national security > adversaries. True. However, there's also tempora as well, so there may be benefits even if not all adversaries are countered. I'm not saying we have a good enough way to do that yet, but increasing the costs to the adversary and forcing what was covert to be more overt is part of the game too. Something that only worked against passive things like tempora could in principle be worthwhile if it forced the adversary to have to get their stuff into the CDN/data-center. If we could do better that'd be great. If we can only counter a tempora-like attack and the costs for doing so are quite high then there would be a case to be made for living with tempora perhaps, but I'd rather not myself. S. > > /r$ > > -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: > rsalz@jabber.me; Twitter: RichSalz > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed May 14 09:13:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340571A02DA for ; Wed, 14 May 2014 09:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oypGoCKa7Cv2 for ; Wed, 14 May 2014 09:13:28 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4641A02E5 for ; Wed, 14 May 2014 09:13:27 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so2731494vcb.15 for ; Wed, 14 May 2014 09:13:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dZ3qtKHg+gm6c2zRqG2edr3OQoE/I5wpnDRxzoEEwG4=; b=kA8z0lVWLoJ2Cr30UWWI3OO/lCXEZahS8i6yUYH2ckUJSxgjXtSriwH4/KkwVF3sqT MYyeMvEqYT/NlvpR8BouxNtLix6jLgLlIODswgrhlNyWe8/6z0GbWgivHqhpxNsoB9Dc WGcx3G8R3t8On+niMyOhq5Zc/B9/cHO4titM+R1CHo5mNJaCUYZ9199e2G037iR0leEv qWX1vHC2Nm4ogiRsprqmCZtixkhfZL3brv/WxR3s6lJuDKbEZyDdQbmO/pacQ+SMZ8hS h/Y533kP3+5icrCBpM/wPM1FuG1mzmm/rpno5hqL082mw1z+JVnu7f1aUNv00vCABvx2 il8w== X-Gm-Message-State: ALoCoQmrxQGncHrszxc1maNLElwVWtY4qM4cbwavLyZJGPWirKIKSr7irHByu3lUbcD1Ib2SO4Ai X-Received: by 10.58.198.75 with SMTP id ja11mr511591vec.59.1400084000111; Wed, 14 May 2014 09:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.246.39 with HTTP; Wed, 14 May 2014 09:13:00 -0700 (PDT) In-Reply-To: <53738AFC.4060904@cs.tcd.ie> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <1400053497.2757.12.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA62A@USMBX1.msg.corp.akamai.com> <53738AFC.4060904@cs.tcd.ie> From: Andy Lutomirski Date: Wed, 14 May 2014 09:13:00 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n7slN5DTlm9i1bmtn2NgFmrDftQ Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:13:36 -0000 On Wed, May 14, 2014 at 8:25 AM, Stephen Farrell wrote: > > > On 14/05/14 16:13, Salz, Rich wrote: >>> Load balancers and redirectors will need to terminate TLS in order >>> to redirect the traffic to the proper host. >> >> Which we know have been interdicted by various national security >> adversaries. > > True. However, there's also tempora as well, so there may be > benefits even if not all adversaries are countered. I'm not > saying we have a good enough way to do that yet, but increasing > the costs to the adversary and forcing what was covert to be > more overt is part of the game too. Something that only worked > against passive things like tempora could in principle be > worthwhile if it forced the adversary to have to get their > stuff into the CDN/data-center. If we could do better that'd > be great. If we can only counter a tempora-like attack and > the costs for doing so are quite high then there would be a > case to be made for living with tempora perhaps, but I'd > rather not myself. My argument is that the cost of countering attacks that don't involve compromising an endpoint should be quite low if done sensibly, and I think that this type of protection could be quite valuable. I agree that having the client cache some kind of public key will be a mess and might not offer any protection, but I don't think that's necessary. If done right, exactly the same protocol change could also counter active attacks based on forging certificates. --Andy From nobody Wed May 14 09:52:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FED81A0305 for ; Wed, 14 May 2014 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL4YaJ1gpqiM for ; Wed, 14 May 2014 09:52:10 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 498B71A02F2 for ; Wed, 14 May 2014 09:52:10 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so8386777wiw.14 for ; Wed, 14 May 2014 09:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ioquE5zRm6h5/Aq5eesctdX7rZsfLAXUFXheyuK3y2U=; b=iq4EuyIv8m4OnW87OWDvjI/0W9e4bvccOhMSa0XOXtX8gDvX95YRSpy8HTLnlC4ElU gwaJQ9y6gbhGiTfFHQYybBi6elFoTJWQkt4LEmBgS+nikqPyJ8KOGKLlqogNzbvX+lbW 9NTS39VsG3THcv6SDHbUNwGZ5lUD84o9b/CbO0yUlymZdnurP4X5phVCvJDAT1dKaVpH yR1SDAmiafoI0qBXK3IfaD3go7oASwM8eA1/bAhub8s2HcuJCult23u9uCatl99/yCR+ w24KvI+SoxISrpeOuM8Tsbqwkhca/h/HN1q7l7gTG5nz2K5dQznbzhAxFb8OficE6XdN 7m4g== MIME-Version: 1.0 X-Received: by 10.194.77.50 with SMTP id p18mr2984669wjw.68.1400086323176; Wed, 14 May 2014 09:52:03 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Wed, 14 May 2014 09:52:03 -0700 (PDT) In-Reply-To: <20140514022007.5C7FD1AD07@ld9781.wdf.sap.corp> References: <53728B78.30306@cs.tcd.ie> <20140514022007.5C7FD1AD07@ld9781.wdf.sap.corp> Date: Wed, 14 May 2014 09:52:03 -0700 Message-ID: From: Martin Thomson To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n7IMzPZCTskAkjUjwE_xGRr-YQY Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:52:12 -0000 On 13 May 2014 19:20, Martin Rex wrote: > When SNI is used for routing, then it MUST be present > on the initial ClientHello on every new connection, or routing > (to other than the default credential) will be impossible. I think that this is a little too strong as a statement. If routing requires a round trip between the router and the client, that still enables routing, albeit at a higher cost. From nobody Wed May 14 10:18:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6846A1A0309 for ; Wed, 14 May 2014 10:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_oP5hUN0cD3 for ; Wed, 14 May 2014 10:18:40 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.247.18]) by ietfa.amsl.com (Postfix) with ESMTP id E983A1A02CC for ; Wed, 14 May 2014 10:18:39 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id F15B04D37B866; Wed, 14 May 2014 12:18:32 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 0E6524D3745E9 for ; Wed, 14 May 2014 12:18:08 -0500 (CDT) Received: from [96.231.225.192] (port=58709 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wkcoh-00086U-Gz for tls@ietf.org; Wed, 14 May 2014 12:18:07 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <1EF6CC5D-CAFB-4572-A7BC-2D84317FB4BE@ieca.com> Date: Wed, 14 May 2014 13:18:05 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 96.231.225.192 X-Exim-ID: 1Wkcoh-00086U-Gz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:58709 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i4CuN_JYHV2xEo8Gxapez3tnycc Subject: [TLS] TLS Interim: Remote Participation Details X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:18:41 -0000 All, The interim meeting is scheduled for: 2014-05-15 from 9am-5pm 2014-05-16 from 9am-2pm Please note that this is MDT =3D Mountain Daylight Time. All participants are bound by the note well: http://www.ietf.org/about/note-well.html The proceedings (agenda, minutes, proceedings) can be found here (look = for the 2014-05-15 tls row): https://www.ietf.org/meeting/interim/proceedings.html =20 There are no slides uploaded yet but they will be as soon as we get = them. For those participating remotely, a TLS jabber room is available as well = as a Webex session; details follow: 1) Jabber tls@jabber.ietf.org Will will draft a jabber scribe to make sure remote questions/comments = are channeled in to the room. The scribe will likely not provide a = transcription of the conversations at the interim but will make sure = remote participants are at a minimum kept abreast of what topic/slide is = being discussed. NOTE: The jabber room logs are archived. 2) Webex NOTE: If you are not speaking please *MUTE* your phone to minimize the = chance for disruptions during the call. NOTE: Webex has a chat facility too, but it=92s probably best to use the = tis@jabber.ietf.org room instead. IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. Meeting Number: 641 574 353=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://ietf.webex.com/ietf/j.php?MTID=3Dmd3309340a0c67250e8e1475f453dd47d= =20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dmd242ff5521eafb70181b8e4fadf24526= =20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 Call-in toll number (US/Canada): 1-650-479-3208=20 Access code:641 574 353=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://ietf.webex.com/ietf/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 turners@ieca.com - better yet do it in the jabber room. To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dmd0c90458f9aa11a22cfc506d1cd80a98= =20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going tohttps://ietf.webex.com/ietf/systemdiagnosis.php.=20 Any questions let us know! spt for the chairs= From dan@blah.is Wed May 14 12:33:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7881A0168 for ; Wed, 14 May 2014 12:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y6toN5qpYU2 for ; Wed, 14 May 2014 12:33:19 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F81A00D5 for ; Wed, 14 May 2014 12:33:19 -0700 (PDT) Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id E380453FBC; Wed, 14 May 2014 12:33:12 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: blah@fruiteater.riseup.net) with ESMTPSA id 59139BFF Message-ID: <5373C4F3.3010602@blah.is> Date: Wed, 14 May 2014 20:33:07 +0100 From: Dan Blah User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: ietf tls Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vr7zvdx5YqpqTWAHahZm69nupWk Subject: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:37:50 -0000 Heya all, To start, I really appreciate what you all are up to here. In particular, the discussions with outcomes having an indirect or direct impact on Internet freedom and technology that advance human rights broadly. I'm writing in both my personal and professional capacity as managing director of the Open Technology Fund. We offer direct and in-kind support to global individuals and organizations confronting the many threats to Internet freedom globally. It's likely you're familiar with some of the 30 odd projects we provide direct support to including Tor, Open Whisper Systems, and Cryptocat. You may know we offer in-kind security and privacy audits to a much broader set of efforts we don't support directly such as TrueCrypt or OpenPGP.js. You may not know we offer in-kind access to secure cloud infrastructure and maintain support for an Internet freedom Digital Emergency Response Team. You don't know about the 30+ websites and numerous individuals we support who work to maintain an inch of free expression from inside countries with repressive regimes that restrict access to online freedom. Many of the discussions and subsequent decisions that move forward here are incredibly important to OTF's work. As such, I wanted to toss in our support for the coming version of TLS 1.3 to "Encrypt as much of the handshake as possible". This should include all of the metadata and TLS-layer routing information. We think by default is important for those threatened users we work closely with. We know this is just a start of a solution and only one aspect of it. We know that significant work needs to be done elsewhere to prevent passive or active tracking, censorship based on DNS, difficult website fingerprinting techniques, and other key threats to Internet freedom. Even those all addressed, in some situations we will fall short of aggressive censors. Despite that, it's a start, it's forward movement, and omitting these features in TLS 1.3 will make it that much easier for censors to silence the voice of journalists, human rights defenders, NGOs, activists, and bloggers around the world. Censorship is real, and we should fight against it where we can. If you smarter folks than I make these changes in TLS 1.3, valid recipients of the online data will be able to handle incoming traffic however they wish, but the networks or repressive governments in-between should not be able to block or degrade service based on plaintext metadata. Daily, we are witness to censorship occurring at the service level in every corner of the world. The effects are felt by small website hosts to Google and Facebook. Leaving some of this information in plaintext may seem insignificant to many here but it's of significant value to those who would suppress free expression online. Surely any crucial increase of free expression we here can give others out weighs technicalities. Thanks in advance! -- Dan Blah pgp 0x36377134 From nobody Wed May 14 13:35:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5491A0129 for ; Wed, 14 May 2014 13:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nho8iJnVLelr for ; Wed, 14 May 2014 13:35:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8951A00AE for ; Wed, 14 May 2014 13:35:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 32E5D28137; Wed, 14 May 2014 20:35:04 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 5788528465; Wed, 14 May 2014 20:35:03 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E33612026; Wed, 14 May 2014 20:35:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 14 May 2014 16:35:02 -0400 From: "Salz, Rich" To: Dan Blah , ietf tls Date: Wed, 14 May 2014 16:35:01 -0400 Thread-Topic: [TLS] In support of encrypting SNI Thread-Index: Ac9vrADfZ3N25646TKauUy41u37QwgAB2pDQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA846@USMBX1.msg.corp.akamai.com> References: <5373C4F3.3010602@blah.is> In-Reply-To: <5373C4F3.3010602@blah.is> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CtfWAfs6gxCg-wNSzJdshpk3228 Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 20:35:13 -0000 Dan, thanks for writing the passionate and detailed note. > . Surely any crucial increase of free expression we here can give others = out weighs technicalities. I just want to let you know that, somewhat sadly, I disagree with the quote= d sentence, and I'm not alone. (Even the author of the "it's an attack" RF= C has said that barring good technical solutions we're unlikely to do it.) = Encrypting the handshake will not prevent passive surveillance. From a tech= nical view, it's not clear it provides enough privacy to justify the non-in= considerable costs. /r$ =20 -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed May 14 13:47:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB141A017E for ; Wed, 14 May 2014 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.653 X-Spam-Level: X-Spam-Status: No, score=-7.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yghOidXC6Ehn for ; Wed, 14 May 2014 13:47:14 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFB1A01B7 for ; Wed, 14 May 2014 13:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=yR5IPLxi0u0i59Y+MAc0lK5meJARR1pKvQhb/vQpq7s=; b=nVluqez/x+MSYGaWIUFdvK3xV9IbVBU8f44YUu0JqegsN3adZYsZ8ZyFPMdOjcbPrDyprzN0q3Ycccs93GyMd04O1mq51fk8I/9Yf3d0jxG7W61Nky39j9/qsJNYBT+x17X9YcmY7smRCF4cA4hixp7sGp6hOqhjcvGBXi9eUqw=; Received: from localhost ([127.0.0.1]:55748 helo=sescenties) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkg4x-0006Yr-Rj; Wed, 14 May 2014 13:47:08 -0700 Date: Wed, 14 May 2014 13:47:07 -0700 From: Seth David Schoen To: Dan Blah Message-ID: <20140514204706.GC8392@sescenties.(null)> References: <5373C4F3.3010602@blah.is> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5373C4F3.3010602@blah.is> User-Agent: Mutt/1.5.21 (2010-09-15) Received-SPF: skipped for local relay Received-SPF: skipped for local relay Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jEIk4TKdEeJf1IuIblQm9FBYIbE Cc: ietf tls Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 20:47:17 -0000 Dan Blah writes: > Many of the discussions and subsequent decisions that move forward here > are incredibly important to OTF's work. As such, I wanted to toss in our > support for the coming version of TLS 1.3 to "Encrypt as much of the > handshake as possible". This should include all of the metadata and > TLS-layer routing information. We think by default is important for > those threatened users we work closely with. I would like to add the Electronic Frontier Foundation's support to this view. We have been learning so much recently about the privacy significance of communications metadata. At the time that many basic Internet protocols and mechanisms were created, the cutting edge of privacy was providing merely optional mechanisms to protect session content. We can see today that protocols that were designed with good engineering intentions in their time are nonetheless leaking a lot of data that is, in fact, sensitive. That includes leakages of unique device and user identifiers, which can even be used to track people's physical whereabouts, as well as leakages of other endpoint identifiers -- like the name of a virtual host. In the modern era, it's good practice to be extremely aggressive about minimizing cleartext data leaks in protocols. SNI and other parts of the TLS handshake are one part of that, and it is worth focusing attention on them to try to protect as much user information as possible. The TLS handshake is a target of scrutiny for censorship as well as surveillance purposes. This is particularly significant since some providers have started to host resources for extremely disparate sites and services (creating much more threshold uncertainty for a censor about what a particular user is actually trying to access). Middleboxes are already able to use SNI for censorship purposes today. It's true that equivalent information can leak in other ways, such as through DNS queries. But as Alyssa Rowan previously noted here, the existence of multiple parallel information leakage sources risks creating a "circular argument of doom and defeat" when attempting to fix any of them -- where we might not try to fix DNS query privacy because of the SNI problem, and vice versa! And even today, some adversaries may well be on-path for observing the TLS handshake but not for observing DNS queries, and vice versa. SNI -- and the rest of the handshake -- isn't the most privacy-sensitive source of information leaks in Internet protocols. (That honor might go to MAC addresses, which allow passively recognizing the presence of particular devices at the data link layer, or to any of several mechanisms at the HTTP layer that allow second or third parties to recognize a particular client over time.) But it's still worth trying to address these information leaks in a modern secure communications protocol. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 From nobody Wed May 14 15:01:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900821A01F6 for ; Wed, 14 May 2014 15:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw5h3EU_PXxv for ; Wed, 14 May 2014 15:01:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DAA241A0203 for ; Wed, 14 May 2014 15:01:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 285B5BE63; Wed, 14 May 2014 23:01:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydQ2PpYa8tMN; Wed, 14 May 2014 23:01:02 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.79.203]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BD14ABE5B; Wed, 14 May 2014 23:01:02 +0100 (IST) Message-ID: <5373E79E.7090008@cs.tcd.ie> Date: Wed, 14 May 2014 23:01:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Salz, Rich" , Dan Blah , ietf tls References: <5373C4F3.3010602@blah.is> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA846@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA846@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lhwL0RBsDuE81pXEplCxeKzvMN0 Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:01:14 -0000 On 14/05/14 21:35, Salz, Rich wrote: > Dan, thanks for writing the passionate and detailed note. > >> . Surely any crucial increase of free expression we here can give >> others out weighs technicalities. > > I just want to let you know that, somewhat sadly, I disagree with the > quoted sentence, and I'm not alone. (Even the author of the "it's an > attack" RFC has said that barring good technical solutions we're > unlikely to do it.) Encrypting the handshake will not prevent passive > surveillance. From a technical view, it's not clear it provides > enough privacy to justify the non-inconsiderable costs. I think you've slightly misinterpreted me there Rich, I'll try be clearer:-) Yes we do need a good technical solution and we don't yet have one written down. There is an of course obvious technical solution for at least passive attacks, but that does have the significant and real negative aspect that you pointed out, so is perhaps not good enough by itself. I'm also less concerned with monetary costs (most who are running large numbers of TLS instances like you guys could afford some monetary costs:-) but more with the architectural problem that the TLS stacks running in different VMs would not be willing to agree on SNI protection algorithms etc. should a solution require those to be the same across all VMs. But I'm not at all clear that's insurmountable really. So same point I made before: we need folks who want this to put in the work to write down their solutions. (And the corollary is that if we don't figure out how to protect SNI then we need to document why fairly well, not necessarily in an RFC, but in some kind of referenceable thing.) Cheers, S. PS: And again, wearing no hats for this conversation. > > /r$ > > -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: > rsalz@jabber.me; Twitter: RichSalz > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > From nobody Wed May 14 15:15:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FF31A0315 for ; Wed, 14 May 2014 15:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha2UCmBkDTOl for ; Wed, 14 May 2014 15:15:40 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7400E1A0302 for ; Wed, 14 May 2014 15:15:40 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 9so190769ykp.41 for ; Wed, 14 May 2014 15:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e5wAur8jQNUyFbZSN04rcFYhCwEfTuJmwJLS+Eihdbg=; b=SHLtlLNboBgDALraree5gdls/vbFOlGh76uAit09Cg/iylMalcovyFW3Th5FLPsQkw Ot1KY5+tM+PZC4fb9NIjglu/ci63KnmjhovqUzV3ytkB19XqpA6jywBb6qJYYeHxAa/X HEraWwHMfBAUkNTDhG1HAiOAIvIU8klcVEyWFqIA6IEclIxDxv4mhpDpT8wq+TBo+ekf mzz3U2q6s4hTW36+xTwQjHKsCBkAB2gi8TSpPXqtORCJR6l38OezwBrMQYw7T9zFK6lK kbguwVmLSoiiHyjU28gdhvL5N6jKnZ9AWql84W5B2PPzKtTkgnBLN7vsSMJE6f6GcUoy ECaQ== MIME-Version: 1.0 X-Received: by 10.236.46.225 with SMTP id r61mr9315305yhb.107.1400105733600; Wed, 14 May 2014 15:15:33 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Wed, 14 May 2014 15:15:33 -0700 (PDT) In-Reply-To: <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 14 May 2014 15:15:33 -0700 Message-ID: From: Watson Ladd To: Seth David Schoen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rWYLB8oUwRzhbyEbufsuTq91d6g Cc: ietf tls Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:15:41 -0000 Dear all, There are several different proposals for encrypted SNI floating around, and I'd like to take the time to summarize them: 1: Use an unauthenticated channel to encrypt the handshake. Adds an extra round trip, unless server goes first. 2: Use an unauthenticated channel, feed key into inner handshake so MITM gets detected. 3: Have DNS records contain a key to use to encrypt the handshake, key shared across sites hosted under the same IP address 4: Encrypt the handshake with a key that is per-site JFK is out because that involves trusting the load balancer. 4 and 3 involve administrative action by websites, and depend on DNSSEC deployment: they are unlikely to be widely deployed. 2 is probably the best bet, but it has a real problem: the load balancer needs to send the key from the channel to the server, necessitating architecture changes. This leaves 1 as a universally deployable solution. It doesn't get very much done for the work it does. It's better than what we have now, but not much. As for algorithms, I think there is much less disagreement than commonly believed: the wrapper for the handshake does not affect the security of the handshake. Sincerely, Watson Ladd From nobody Wed May 14 17:32:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54AE1A037D for ; Wed, 14 May 2014 17:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfaEoYZ9f2hD for ; Wed, 14 May 2014 17:32:42 -0700 (PDT) Received: from ex10ed04.qut.edu.au (ex10ed04.qut.edu.au [131.181.191.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD5A1A0207 for ; Wed, 14 May 2014 17:32:40 -0700 (PDT) Received: from EX10HT08.qut.edu.au (131.181.108.110) by ex10ed04.qut.edu.au (131.181.191.17) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 15 May 2014 10:32:13 +1000 Received: from EX10MB4.qut.edu.au ([169.254.6.187]) by EX10HT08.qut.edu.au ([131.181.108.110]) with mapi id 14.03.0158.001; Thu, 15 May 2014 10:32:30 +1000 From: Douglas Stebila To: "" Thread-Topic: Server signature in signed-Diffie-Hellman Thread-Index: AQHPb9Un0HMdwspOu02XGu8Zp/nBSw== Date: Thu, 15 May 2014 00:32:30 +0000 Message-ID: <5076B431-5716-47D3-B217-1339D3D9345F@qut.edu.au> Accept-Language: en-CA, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.181.118.223] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SGCriH1ZrvE4uXyvqiPS8n9jgbU Subject: [TLS] Server signature in signed-Diffie-Hellman X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 00:32:46 -0000 The TLS 1.3 wish list makes mention of modifying what is signed by the serv= er in signed-Diffie-Hellman ciphersuites to avoid the cross-ciphersuite att= ack of Mavrogiannopoulos et al. (CCS 2013). Presumably this change would b= e for the server to sign the entire transcript up until that point, just li= ke the client does in its CertificateVerify message, which is a very good i= dea. If changes to the server signature are in the cards, I'd propose that we fu= rther separate the signature from the ServerKeyExchange, and move the serve= r's signature to a separate CertificateVerify message immediately before th= e [ChangeCipherSpec], just like on the client side. While there are no attacks involved in the server signature being in its cu= rrent location, it is not very "clean" from a cryptographic perspective, as= can be seen in the hoops that Jager et al. (CRYPTO 2012) and Krawczyk et a= l. (CRYPTO 2013) had to go through in order to prove signed-DH secure. Rig= ht now, server-to-client authentication can be broken by an adversary who c= an break the signature scheme (at the point of the ServerKeyExchange messag= e) OR who can break the DH key exchange (at the point of the Finished messa= ge). As a result, the server-to-client authentication proofs in the aforem= entioned papers have to make use of a Diffie-Hellman assumption, and in par= ticular had to invent a non-standard DH assumption called PRF-ODH because t= he Finished message is encrypted under the session key. Moving the server'= s signature to a separate CertificateVerify message just before the [Change= CipherSpec] should alleviate the need for server-to-client authentication t= o also depend on PRF-ODH, instead leaving it to depend solely on the securi= ty of the signature scheme. SSH uses this structure for signed-DH, and we = were able to make a proof of server-to-client authentication go through jus= t assuming the security of the signature scheme (http://eprint.iacr.org/201= 3/813). =20 There's no particular reason to doubt the security of PRF-ODH as Watson exp= lained on the CFRG mailing list. But things might change if/when we move t= o post-quantum key exchange primitives. For example, oracle-ring-learning-= with-errors is insecure even if ring-learning-with-errors is secure (http:/= /eprint.iacr.org/2014/070, section 5.3). This doesn't take into account engineering / performance challenges or bene= fits, which I hope others on the list can illuminate. Off the top of my head, this could slightly reduce load on the server due t= o malicious clients. At present, a malicious client can make the server do= a group operation (generate ServerKeyExchange ephemeral public key), signa= ture (sign ServerKeyExchange), and another group operation (generate pre-ma= ster secret) before the server realizes the client's handshake is invalid (= failed Finished message). Moving the server signature later would mean the= server doesn't have to sign until after it has verified the client's Finis= hed message, saving one public key operation. I guess the flip side is tha= t client's can't reject as early, but that seems like less of a concern. Were there particular reasons why the server signature was put where it is = when SSL/TLS was original designed? Douglas= From nobody Wed May 14 18:24:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268901A038A for ; Wed, 14 May 2014 18:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ4vFsRN-Xib for ; Wed, 14 May 2014 18:24:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19211A00F9 for ; Wed, 14 May 2014 18:24:26 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s4F1OHGj024579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 03:24:17 +0200 (MEST) In-Reply-To: <5076B431-5716-47D3-B217-1339D3D9345F@qut.edu.au> To: Douglas Stebila Date: Thu, 15 May 2014 03:24:17 +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: <20140515012417.220D91AD06@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ybhGsvN-sWUcfCN1IP4U1U3h-o8 Cc: "" Subject: Re: [TLS] Server signature in signed-Diffie-Hellman X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 01:24:29 -0000 Douglas Stebila wrote: > > The TLS 1.3 wish list makes mention of modifying what is signed > by the server in signed-Diffie-Hellman ciphersuites to avoid the > cross-ciphersuite attack of Mavrogiannopoulos et al. (CCS 2013). > Presumably this change would be for the server to sign the entire > transcript up until that point, just like the client does in its > CertificateVerify message, which is a very good idea. > > If changes to the server signature are in the cards, I'd propose > that we further separate the signature from the ServerKeyExchange, > and move the server's signature to a separate CertificateVerify > message immediately before the [ChangeCipherSpec], just like on > the client side. Having the server use a CertificateVerify message closer to what the client uses seems OK, but moving it past ServerHelloDone does not seem like a good idea. Recall the full handshake messages: https://tools.ietf.org/html/rfc5246 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake With a (Server)CertificateVerify just prior to ServerHelloDone, the client would be able to verify the server certificate before sending his own certificate, so the client would be able to limit which servers (attackers) it is willing to disclose a client certificate to. In the existing TLS protocol versions, an active attacker can always make a client disclose his client certificate by doing an MITM on the beginning of the TLS handshake. Admittedly, a real benefit will only materialize if TLSv1.3 provides confidentiality protection for the Client's Certificate handshake message. -Martin From nobody Wed May 14 20:31:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730CD1A021B for ; Wed, 14 May 2014 20:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei9gHIWGwcAK for ; Wed, 14 May 2014 20:31:32 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB871A01EB for ; Wed, 14 May 2014 20:31:31 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so9077630wiw.14 for ; Wed, 14 May 2014 20:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8G4QjLdXQbxDYA81wI/e9sATkeVVAPUI5VaZgU1eZS0=; b=vlrZOpAzC1FD9de57U3CGKBUZU6bN6jZPki7+CRSyYps+hAAkz7aCCOkCRuCnTcHXb MPJlH/GIYIqKBl3KRxSvC7ywDLa79BO29HIxlRwODaPVkiwoGpVPr87Um57eKSWiMPFY HTI3al24Ldg5eCKgNUQhKRhE0z2qzZ1VkVXc4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8G4QjLdXQbxDYA81wI/e9sATkeVVAPUI5VaZgU1eZS0=; b=lQulRNOmQPOUJddVoyu4vHU/9d0Yilr+Zz+jpDbPHhTupGYaqm4EsS8zRYOK4/K0S0 3MHe9GdTFJUoOJ4sj2+BU1i9EmoLKpWJVMKNXoNRW0WafT7vdTic/aSB9kKo/LumRJxT q/MsyesVVTu8QDq/GD9NujVbvfeTnaG0b8QrsbaqvUgbSdLHOP42gw7mlMLH2wZWT57q f0QaAjAfYskFUBqvXKle6jdsKqTGUqgAcvXr5rAszO86G7nNTAGF9Dv182wvEpgThXn7 fl5lCrTnjKS3yTAnB1IpeIUBXfjV/vnLKjU2pnRgKYjw97woTJ3D0qHBnJDIbhxg3MMl HuMw== X-Gm-Message-State: ALoCoQmcvMPjGiqx+xCIyyIpalmF1d2f9Z7j7WhGd11QmkgDDglMSQ6TYTWyTKFNomondVirVLwH X-Received: by 10.180.211.243 with SMTP id nf19mr6356444wic.58.1400124684155; Wed, 14 May 2014 20:31:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.58.134 with HTTP; Wed, 14 May 2014 20:31:04 -0700 (PDT) In-Reply-To: <53727940.2070900@nthpermutation.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <2A0EFB9C05D0164E98F19BB0AF3708C7130ABEA050@USMBX1.msg.corp.akamai.com> <53725C34.8060105@fifthhorseman.net> <53727940.2070900@nthpermutation.com> From: Tom Ritter Date: Wed, 14 May 2014 23:31:04 -0400 Message-ID: To: Michael StJohns Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RgasPjSIZ4NH4khPhH5cPQmHA74 Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI - Traffic Analysis Attacks? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 03:31:34 -0000 I have a lot of points on Encrypted SNI, so I'm looking forward to tomorrow, but I wanted to start putting some into email. I'd like to start with the notion that HTTPS fingerprinting makes it useless. One of the best surveys of the literatre is Roger Dingledine's blog post at https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks. (It does not include the most recent paper "I know why you went to the Clinic" by Miller et al.) There are lots of scenarios for HTTPS fingerprinting, and it's important to note that he concerns himself with Tor's use case: the adversary is trying to do fingerprinting when the client is potentially accessing the entire Internet. Some of the other scenarios considered in literature are a) determining which webPAGE is visited in a specific webSITE and b) determining which webPAGE you are visiting among many webPAGES on many (but finite) webSITES. An arguement that Encrypted SNI or Server Certificate (taken together, Encrypted Handshake) is not useful is absolutely correct if there is only one webSITE hosted on an IP address. The IP gives it away, regardless of DNS Privacy, Encrypted Handshake, etc (so long as the attacker can index the site, and we assume they can.) So I'd like to instead talk about the case when there is multiple webSITEs hosted at an IP, and an attacker wishes to determine which webSITE in a set of webSITEs the user is visiting - because that is the metadata that Encrypted Handshake protects against. Unfortunetly, there are no studies that attempt this, of course. But we can still talk about some stuff. First off, because we assume that the attacker knows all the websites hosted on an IP, it's a closed world study, an advantage to the attacker, they're much easier. However, even a 'closed world' is not truly closed. For a true closed world, an attacker must be able to train their classification engine on all the pages in the site. Dynamic content that changes via authentication, and just general additional data added to the page since classification (think comments, posts, etc) make this impossible. All of the studies do not attempt to deal with this problem. The attacker's advantage is not taken away, but it is ever so slightly reduced. But there are other things that make the closed world less closed: client beahvior. Caching, AdBlocking, Plugin Click-To-Play, Third-PArty Cookies Enabled/Disabled, Ads, Javascript Disabled and so on. Advantaged reduced a little bit again, although Miller attempts to address the caching one. Next off: False Positives Matter. A Lot. I'm basically just going to point you to the same section in Roger's blog post. Summed up and applied to us, it states that if your goal is to determine if a user is visiting Site A on IP X, instead of Site B - the false positive rate keeps adding up on each page load. You're not going to get a binary answer, you're more likely to get an answer that looks like "Well, we had 8 hits for SiteA, 10 for SiteB, 3 for SiteC". Advantage to the Defender. Finally, there are defenses a website concerned about this can employ. There are a number of different padding mechanisms for defenders to deploy, collected from many papers and outlined in Section 7 of the Miller paper. All of these defenses can be deployed unilaterally by the server (no client changes needed), inside of the TLS protocol, with the simple ability to insert random padding ignored by the client. I've seen this topic come up before, and I hope people are not opposed to this optional feature being present. So at this point I'd like to talk about the most recent paper, "I know why you went to the Clinic" by Miller et al. At a high level, they attempt to identify which webPAGE you are viewing inside a known webSITE. Different from our goal, but we're not speaking different languages. I'm going to liberally take excepts from it that in the real world will reduce their impressive claim of 89% accuracy. - They don't operate on whole sites, they took a subset of the site, 500 'labels' (unique pages), followed redirections, and ran it off that - They didn't operate on single loads, they visited 75 pages in a session and each page they collected 16 times. - They discover and remark that "caching significantly decreases the number of unique packet sizes observed for samples of a given label" and that "A reduction in the number of unique packet sizes reduces the number of non-zero features and creates difficulty in distinguishing samples." - said another way: caching makes it harder - They also find that visiting webPAGEs on a webSITE (as opposed to different webSITEs) causes decreased traffic volume, which also makes it harder. This is our scenario. - Their accuracy went from 72% to 89% by using a Hidden Markov Model. While this is not bad, strictly speaking, it assumes that the user follows the link structure of the site strictly. No bookmarks. They also don't factor in the possibility of 'Back' buttons (Although I suspect most websites that link A->B also link B->A so it's probably accounted for most of the time.) - They used 500 labels for their subset, the 4 sites whose redirections ballooned that up (to ~1000 labels) had the worst accuracy. Logical, but nice to see confirmation that the larger the site, the worse accuracy. - They do not factor in browser differences, OS differences, or user configuration of the browser - They present a defense that takes their own accuracy from 89% to 27%, with only 9% traffic overhead Perhaps most unrealistic: They assume users browsing with a single tab and easily delineated page requests. No mashing the refresh button, no multiple tabs, no opening in a background tab, no background tab that's doing AJAX polling, etc. There are some very sexy presentations on HTTPS Traffic Fingerprinting, probably the sexiest of which is watching you load Google Map Tiles over HTTPS, and detecting where you're zooming in on. But that presentation, and the papers, all assume a very unrealistic operating environment. Which is not to denigrate them, I think they're generally excellent work and foundations for further research. But you can't point to them and say the situation is hopeless. At this point, I'm actually pretty optimistic that attacks in the real world will be quite difficult. Trying to defeat Encrypted Handshake using HTTPS Traffic Analysis has a lot of things going against it: 1) The adversary's determination of Site A vs Site B is made significantly more difficult by cumulative false positives 2) The greater number of sites hosted at an address, the more difficult his job becomes. 3) The attacker has to do a considerable amount of work to train their classifier for the specific user preference that matches the user they're attacking 4) And factor in the current cache state of the user 5) A site can actively try and defend against it, and we have indications this would be very effective To put a point on active defenses: I think a lot of people assume that would never happen, but Twitter is currently padding profile images to resist traffic analysis. In the future, I expect more sites will start to care, and more people will ask them to. One of the things I think would be awesome was if a research project was done on this exact problem. I think that a CDN could provide accurate numbers for the characteristics and numbers of sites hosted on an IP address, which would be much better than arbitrarily chosen numbers. However negative results, that is results that say "We couldn't get good accuracy" often are not published, so we'd want to see those too ;) -tom From michael@accessnow.org Wed May 14 21:56:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225D31A03CC for ; Wed, 14 May 2014 21:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_FSL_HELO_BARE_IP_2=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AqKVsl0B5V0 for ; Wed, 14 May 2014 21:56:17 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFBC1A03CD for ; Wed, 14 May 2014 21:56:15 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id d17so223353eek.2 for ; Wed, 14 May 2014 21:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :content-type; bh=MMU9r4d9RR1GdNMxXuxZD2pujDTdQ22xPr91O9tfe2M=; b=CJybkO36anmn2f28na+9TqhBz1IuZJVi7mv7/TMOHt6SfubZoHhb+fUdssuurbN9Di NUKpaKrAKCZPnqkXZQz2Il6/YGy7MXlwi+n/BiBnt9OgefDuxcbgRJ8wL4oHYkdeWq2R sMxGWBHILfZi1kJh1/AIgp9+cWy8aSktIW69rlpQvi2Ua7ctTT7NlzoSrasAi85gqWDT T+FNWlREe4WT1OztlWCfRWjRx+wHhn7fHkpvvnoQsKf87pulrRcXevNmKxfhbbt6FB7a GRpnTvxMPpfaPYZLZqMrWOmBuCeRk4UrH56InS2WkaXxRJ8QsEYocE0Jz6LqlIlloq2M aiJw== X-Gm-Message-State: ALoCoQmZCotXWkSimIYU2Cii8NLC4RbnHydyMzaapmi5nLa4rbkbBlUFzOzsbNRO9SgsBWRI9eXr X-Received: by 10.14.2.131 with SMTP id 3mr11128411eef.45.1400129768192; Wed, 14 May 2014 21:56:08 -0700 (PDT) Received: from 127.0.0.1 (rainbowwarrior.torservers.net. [77.247.181.164]) by mx.google.com with ESMTPSA id x43sm9747120eeo.26.2014.05.14.21.56.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 21:56:07 -0700 (PDT) Message-ID: <537448DD.7010806@accessnow.org> Date: Thu, 15 May 2014 00:55:57 -0400 From: Michael Carbone MIME-Version: 1.0 To: tls@ietf.org Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rCHAAbVwIFoblhBWCiPMouMIBWX4g8rmR" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/59Bqg82CMoZj0eISXlKlOLeC1J0 Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 05:00:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rCHAAbVwIFoblhBWCiPMouMIBWX4g8rmR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seth Schoen writes: >> Dan Blah writes: Many of the discussions and subsequent decisions=20 >> that move forward here are incredibly important to OTF's work. As=20 >> such, I wanted to toss in our support for the coming version of TLS >> 1.3 to "Encrypt as much of the handshake as possible". This should >> include all of the metadata and TLS-layer routing information. We >> think by default is important for those threatened users we work >> closely with. > I would like to add the Electronic Frontier Foundation's support to=20 > this view. We have been learning so much recently about the privacy=20 > significance of communications metadata. At the time that many basic > Internet protocols and mechanisms were created, the cutting edge of > privacy was providing merely optional mechanisms to protect session > content. Hi folks, Access shares this view and we would like to add our strong support with Dan at OTF and Seth at EFF for encrypting the TLS handshake by default in TLS 1.3 -- protecting the server certificate, a client certificate if used, and all TLS-layer metadata/routing information, such as SNI and ALPN. Access is an international human rights organization that uses policy, user engagement, and direct technical support to defend and extend the digital rights of users at-risk around the world. The global Access community is nearly half a million strong, and we have provided technical support to civil society organizations and human rights defenders in over 35 countries. This direct technical support is provided by our digital security helpline staff to individuals and organizations in high-risk environments, helping these targeted groups securely host content online, mitigate digital attacks such as DDoS, secure their communications, bypass censorship, and defend against surveillance. In addition to helping protect the privacy of such users from surveillance, encrypting the TLS handshake by default would better enable the access to otherwise censored websites and services, especially if they are served through unblocked content delivery networks (see the "Collateral Freedom" report for further details on this particular access strategy). As Dan and Seth have mentioned, we recognize that such a move will not solve all access or surveillance problems by itself (hence DNSCrypt etc), but I hope we all recognize that it would be a tremendous step forward in enabling users to more securely exercise their rights online, especially those most at-risk. For us, attempting to encrypt TLS handshakes by default is part of a broader movement of platforms, companies, and projects to rethink the default security position they provide users. Given the ease by which unauthorized actors can access large amounts of personal information without any judicial process or oversight, and the lack of awareness or control users have in the security of their online interactions, we all need to evaluate the ways we can make encryption more accessible and ubiquitous for users. Our Encrypt All The Things campaign (https://encryptallthethings.net) outlines some steps designed to ensure a minimum level of default security for users online, and we believe supporting the IETF in its consideration of more ubiquitous default security for internet users fits strongly into this movement. We hope the IETF considers the needs of at-risk users as well as of all of us targeted by pervasive monitoring in supporting encrypted TLS handshakes by default. Best, Michael --=20 Michael Carbone Manager of Tech Policy & Programs Access | https://www.accessnow.org GPG: 0x81B7A13E Fingerprint: 25EC 1D0F 2D44 C4F4 5BEF EF83 C471 AD94 81B7 A13E --rCHAAbVwIFoblhBWCiPMouMIBWX4g8rmR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTdEjjAAoJEDH9usG3Jz33FaQP/3h1F8Je0MxXijg3ivG7w0Cz K4UeAmtWPPi2afclOORA/82SihE0oeb594xh200Vm1j1rjwdUWtp/VMMFto7qZN7 g9ZXtK+3UzjDcpcAI18CtyJhM8keIu06gQ448H0Qi3B5ruHfoym7bfoETsk2pfYD ouTeDRGL8xNradbU1U6o2GaqHfp8WRdLNPkC68djfBMaDLcAPdnComUFBZ13T16L uyi12b2DFt7LaicU3vDGAenxJhu2pfY6ZO4/wY/Bkq9LNHVXRU2axcNLZuf7AO6w K+rjTNzGsV0wfhV74dUtB+ZP1bVa1vwU96s7+c7dWj+Uk4XkSw3bQKZtQ3Aqz1xY ayHv5lgNqe5vzulpez0JS8uClm0xPz5vWVvBqBA5jFrW7DT7gQFoNGbEb/AGb/1y ahmeugz/LasMOM+rZhI3froh8a2pgA6wIG+UBAZZNS1LYTiDAcuXcbhfohkbd0R3 q55G72Xlkr2sREDZPflS8APCGeGkrbUdsBakbWagZ0EL6d1gaDgxkCw/GhC99Q/J Cu6//ypFM6Vm+qbk782hIWYF5jMsY4HnHBeWj/AH516t9El1DYPTd7WjQ8M7iRda H2m8MwMfko9PgEK0uHhIaY9JxStcRBN8aC9xXpHDE45Dv1s90PSmsta1gOKkB3NB e7udJRgvCZ70myGz7sSP =Jcei -----END PGP SIGNATURE----- --rCHAAbVwIFoblhBWCiPMouMIBWX4g8rmR-- From nobody Wed May 14 22:23:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B701A03CE for ; Wed, 14 May 2014 22:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSPNkYL0jJmQ for ; Wed, 14 May 2014 22:23:31 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2F11A01F9 for ; Wed, 14 May 2014 22:23:30 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 142so482930ykq.16 for ; Wed, 14 May 2014 22:23:23 -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:content-type; bh=k6fc4qi50Z4WR2K8AZa8I9SzHMljggdhxfHUZvX39Lk=; b=hDAVe4et01z2sheJWiqd14W225IW1s7VZtWaGF7JyAStmHyMI52zSZvR3V8H8w+jUq hNAy6fgqv7EzscudHbxvFy+fTK7GhzXvpbIAek8ilRLmaYAieFuzLNHSuXWkT97Ylo0r PkOByowVfMjV5hFAeV84Fp37mZpC9X18oXcK7I2vcpKmdkDOIBcXcPNJuVgP38B0rh/O 8m07EUDxjVukvkdvwPucj63o7rat33aHXGrTKe7Dko5w0BGQ+yht3wWPDT+v3GD+2PtK ajUqu2Qm97h0mgkbc5e5TZ/GuLGVZ1IV5pdh+/AwuFICXQhQGRKQgcmz61Vyp2Bpv+M5 lOyQ== MIME-Version: 1.0 X-Received: by 10.236.50.229 with SMTP id z65mr3209162yhb.120.1400131403510; Wed, 14 May 2014 22:23:23 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Wed, 14 May 2014 22:23:23 -0700 (PDT) Date: Wed, 14 May 2014 22:23:23 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1EJUQDvNlZjaS5iihoCOsY_WYek Subject: [TLS] Simplify, simplify, simplify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 05:23:32 -0000 Dear all, As we are about to embark on a meeting to produce a protocol, let me bring forwards what a veteran IETF participant believes about protocols: https://www.w3.org/2014/strint/papers/34.pdf If TLS 1.3 is easier to deploy then TLS 1.2 it will be deployed. Otherwise it will not be. Some of the specific recommendations are for other WGs (in particular DANE, DNSSEC, and whoever is in charge of the mess that is PKIX), but I think that the bottom-line message is worth listening to: simplicity is the single most important criterion for a security protocol. Sincerely, Watson Ladd From nobody Wed May 14 22:40:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611F1A0225 for ; Wed, 14 May 2014 22:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQsNYqXvidbU for ; Wed, 14 May 2014 22:40:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (sasl.smtp.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id DFCD91A0239 for ; Wed, 14 May 2014 22:40:54 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 28F17115AE; Thu, 15 May 2014 01:40:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Pq0Qtgddw/R6 Bm6AQ2y7Ty+S3l0=; b=Kz0SET2t4+vOyRVLFjaI045H/vMcIEZ4bSTl3iUMhbzp ifg7nCvOeFMw8gz90m1DfvVKGdCWubY2/mf+fFKNmIDxPzzKWoLeSwjRnnQeNp6I Hvswvm8ZBIXrXAVNUDxI8te6uHq2KHGPAt8bnTCRtoYLyOXQureChDZALdd5iJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=sgJZuX UUvMWmmHhIuWNnAcgQYKrIwiNTr48cQVZ91MbLYvSaROK6XYFSBFlBd8MchWObk3 cZgLAb6DJIQHLYqPmiIDvLBFFI4vpFRUjanJ8BEeUZSAJRuoCzo1ynRpweROhZ4f u2PvGLfAT/CECl0lMamMzGaJDXv7HAMO18Gqo= Received: from pb-sasl0.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl0.pobox.com (Postfix) with ESMTP id 13403115A9; Thu, 15 May 2014 01:40:47 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl0.pobox.com (Postfix) with ESMTPSA id 0772B115A8; Thu, 15 May 2014 01:40:38 -0400 (EDT) Message-ID: <53745355.2010708@pobox.com> Date: Wed, 14 May 2014 22:40:37 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Watson Ladd References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7248DF24-DBF3-11E3-8BDC-D22C48B83612-38729857!pb-sasl0.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qB-t5A9GSEe1ZPluWWuMXYg7pk4 Cc: "tls@ietf.org" Subject: Re: [TLS] Simplify, simplify, simplify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 05:40:57 -0000 How do you get around the way version negotiation works? If a client asks for TLS 1.3, and the server doesn't support it so it replies with TLS 1.2, the client has to know how to speak 1.2. There's no way for the client to say it supports TLS 1.0 and 1.3, but not 1.1 or 1.2. Mike Watson Ladd wrote: > Dear all, > > As we are about to embark on a meeting to produce a protocol, let me > bring forwards what a veteran IETF participant believes about > protocols: > https://www.w3.org/2014/strint/papers/34.pdf > > If TLS 1.3 is easier to deploy then TLS 1.2 it will be deployed. > Otherwise it will not be. Some of the specific recommendations are for > other WGs (in particular DANE, DNSSEC, and whoever is in charge of the > mess that is PKIX), but I think that the bottom-line message is worth > listening to: simplicity is the single most important criterion for a > security protocol. > > Sincerely, > Watson Ladd From nobody Wed May 14 23:07:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEE51A03DD for ; Wed, 14 May 2014 23:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5PN3e5rlt8X for ; Wed, 14 May 2014 23:07:20 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7811A03D9 for ; Wed, 14 May 2014 23:07:20 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id up15so646889pbc.16 for ; Wed, 14 May 2014 23:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlY+bToet4JhNIUGtzCJQ5/WoAZWc07dceRpTuZEvDo=; b=VUuagBODa9fDyoNCA8tNAEpTeWK6cy1+uPAAye52xj1cJSBSOmgV1zsr3SnpRUcj/D wbRQIOyox+odiGCxTrInhhzQq9+LHKSnD+dMeGN3iXrap/aZXkGk7ah2rC9Y2Yxxxljs KPFzKAhdjaAmiYEbyG3tsLSl8URfYnI6PgXs1KPlhK+J3xGryEkcQtuXXGcVrppuNmx+ Cr72sSU+Y8lKlZEuhsQVIUiB/mkfhkFumQkEMv32jI5I4mWAh0cDVemyXX4f+rHjQc4F gZtC0sQkIjbUdkBiCKbRpRiuKP9NDd+HSD0qX6FrS3jfgxFNxRCHklWvxFGql7MB4rFe h3Vw== X-Received: by 10.66.102.74 with SMTP id fm10mr10164855pab.86.1400134033710; Wed, 14 May 2014 23:07:13 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id rw4sm16756451pab.47.2014.05.14.23.07.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 23:07:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D167) In-Reply-To: <53745355.2010708@pobox.com> Date: Wed, 14 May 2014 23:07:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53745355.2010708@pobox.com> To: Michael D'Errico Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KwGZLGJ0r9cf9neC49_Z11LLw80 Cc: "tls@ietf.org" Subject: Re: [TLS] Simplify, simplify, simplify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 06:07:25 -0000 > On May 14, 2014, at 22:40, Michael D'Errico wrote: >=20 > How do you get around the way version negotiation works? If a client > asks for TLS 1.3, and the server doesn't support it so it replies with > TLS 1.2, the client has to know how to speak 1.2. No, at that point the client can refuse to speak TLS 1.2 and abort the conne= ction, ... then restart a new connection using it's legacy TLS 1.0 implementation.=20= > There's no way for > the client to say it supports TLS 1.0 and 1.3, but not 1.1 or 1.2 You could also have out of band indications of what the servers support, so t= hat you avoid the reconnection in most cases.=20 I don't see a simple and efficient way though, so I guess you have a point..= . >=20 > Mike >=20 >=20 >=20 > Watson Ladd wrote: >> Dear all, >> As we are about to embark on a meeting to produce a protocol, let me >> bring forwards what a veteran IETF participant believes about >> protocols: >> https://www.w3.org/2014/strint/papers/34.pdf >> If TLS 1.3 is easier to deploy then TLS 1.2 it will be deployed. >> Otherwise it will not be. Some of the specific recommendations are for >> other WGs (in particular DANE, DNSSEC, and whoever is in charge of the >> mess that is PKIX), but I think that the bottom-line message is worth >> listening to: simplicity is the single most important criterion for a >> security protocol. >> Sincerely, >> Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed May 14 23:23:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB8D1A03DC for ; Wed, 14 May 2014 23:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRMP6w9kxLVX for ; Wed, 14 May 2014 23:23:34 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8B91A03D9 for ; Wed, 14 May 2014 23:23:34 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kq14so651182pab.5 for ; Wed, 14 May 2014 23:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EBUfzs0aR3lGreV/FqogGT+ZYkR/p6ftEsY7LnC+NMQ=; b=H3pfcpGobaMZ6j10QoEfwl0MmWWr6jxyuj2WpUGFwg/M8Mhcfmh7HXqH+2phi3RPLz higTHsEsc2grs9ejvS0iaNjJAgHHpCwiTteEt1HQIjB2QFGEdmfznHZpHPcCRsdOJ48U CoQdCV+7JHsbzQg/Rc8BeLj/HNlSce+OcHoGbjwcqFhq7HdYpUi5i7YB78OUW8T/qawQ tx4Df5GTKivLOQiGScmsSg8DVBYU7WgW5wj6E9g92w+XVFb/cPYX/Y7eCeH3zBz2kDvd bX4jN2RV782LZRMrb5NLOBex+vGAUlR1EC8Q1CtrMHwhpGJLDKSb8F85GuhlNZbyqjVT 2pDA== X-Received: by 10.69.31.107 with SMTP id kl11mr10019713pbd.142.1400135007163; Wed, 14 May 2014 23:23:27 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id tb4sm16934090pac.45.2014.05.14.23.23.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 23:23:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Wed, 14 May 2014 23:23:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> To: Watson Ladd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vbyr35kijlsyGbqif-bYY0fHbeI Cc: ietf tls Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 06:23:36 -0000 > On May 14, 2014, at 15:15, Watson Ladd wrote: >=20 > Dear all, > There are several different proposals for encrypted SNI floating > around, and I'd like to take the time to summarize them: [...] > 3: Have DNS records contain a key to use to encrypt the handshake, key > shared across sites hosted under the same IP address > 4: Encrypt the handshake with a key that is per-site >=20 > [...] 4 and 3 > involve administrative action by websites, and depend on DNSSEC > deployment: they are unlikely to be widely deployed. If a comprehensive solution to the surveillance problem also involve changes= to plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the= solution depends on the DNS bits being deployed as well? -- Fabrice= From nobody Wed May 14 23:30:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989421A03DC for ; Wed, 14 May 2014 23:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo52b88PfM0x for ; Wed, 14 May 2014 23:30:18 -0700 (PDT) Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA941A03DD for ; Wed, 14 May 2014 23:30:18 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1WkpBB-0003vc-S2 for tls@ietf.org; Thu, 15 May 2014 02:30:10 -0400 Received: (qmail 12631 invoked from network); 15 May 2014 06:30:08 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 May 2014 06:30:08 -0000 From: "Christian Huitema" To: "'Fabrice'" , "'Watson Ladd'" References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> In-Reply-To: <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> Date: Wed, 14 May 2014 23:30:04 -0700 Message-ID: <04d201cf7007$1c24ced0$546e6c70$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKg8SzXu2Eac0zVv95W4046OeJi6wIjRBBYAlsl78cAmpui1Jl1Y0sg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8Jm4eUCGB-4uK4tUZZooG2ljfeQ Cc: 'ietf tls' Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 06:30:20 -0000 > If a comprehensive solution to the surveillance problem also involve changes to > plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the solution > depends on the DNS bits being deployed as well? This is a bit close to the "your side of the boat is leaking more than mine" argument. Let's plug both leaks, and not have each wait for the other. -- Christian Huitema From nobody Wed May 14 23:34:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C591A03E3 for ; Wed, 14 May 2014 23:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHlDfN8sPtOP for ; Wed, 14 May 2014 23:34:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03F1A03DC for ; Wed, 14 May 2014 23:34:15 -0700 (PDT) Received: from [10.111.101.241] (unknown [67.128.140.2]) by che.mayfirst.org (Postfix) with ESMTPSA id 6E9FBF984; Thu, 15 May 2014 02:34:05 -0400 (EDT) Message-ID: <53745FDC.8020708@fifthhorseman.net> Date: Thu, 15 May 2014 00:34:04 -0600 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Fabrice , Watson Ladd References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> In-Reply-To: <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qpi0JbQCMhe6tNKXjnKMHRcwHdrWogWin" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-nJ2fP2yw92QwOd5Dh6WXto5H_I Cc: ietf tls Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 06:34:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qpi0JbQCMhe6tNKXjnKMHRcwHdrWogWin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/15/2014 12:23 AM, Fabrice wrote: >> On May 14, 2014, at 15:15, Watson Ladd wrote: >> >> Dear all, >> There are several different proposals for encrypted SNI floating >> around, and I'd like to take the time to summarize them: > [...] >> 3: Have DNS records contain a key to use to encrypt the handshake, key= >> shared across sites hosted under the same IP address >> 4: Encrypt the handshake with a key that is per-site >> >> [...] 4 and 3 >> involve administrative action by websites, and depend on DNSSEC >> deployment: they are unlikely to be widely deployed. >=20 > If a comprehensive solution to the surveillance problem also involve ch= anges to plug leaks by DNS, wouldn't it be reasonable that the TLS portio= n of the solution depends on the DNS bits being deployed as well? Or, to look at it slightly differently: we can deploy TLS with an encrypted handshake that is protected against passive monitoring even in the absence of DNSSEC. And when DNSSEC is available, it becomes possible to detect or prevent active attacks. There's no reason to wait for DNSSEC to become available to start to use mechanisms that would protect against passive monitoring in its absence. --dkg --qpi0JbQCMhe6tNKXjnKMHRcwHdrWogWin Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTdF/cXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcAUIQAINzCR2cQwFze8uDcsCAD8aB mjTNMd2tHcxYH2tBm8kK7YG9p0zosSJBBXV9VnVfjOQYMxrL8p9n/V1ellMClIot OJcD2daiPwfGZEM2l9SYlLXspeZHq6t6qblke+IsC9Rie2buiCOvPPVoNYnEJ9p3 0lKpEVezENP1f/h1rYo7WMhbSKoaGVhLJRmHPpU5+9eek4t1CGTgr7/iiM95+g37 RYdfM3iNNfWypRd9/CaBptKZLxKmpKfiVXUvtw2DUIPu/vvLrF85p7P/TeeS8Kx+ 56lFTqKpK7pOn3cNChBTrpCVkhx383XGtUfBqoF859+SRFmLg/5j7WNkKCe3ju6R 9ESUHQr49O/B5NaUVYvu/Q2ztbYedfqNDbKickAKlBWdTZ3S6FbqSlAXVydt6j+0 vIQJ06lJxXsz66geN+euEwa0zIhkthzw7YOtfornCbmBLjXxPQGuJgTB0+5TsiFf /vPhf7g1XJBvBe3Q6/O4nzbJgwTAP5nLdbSOM+dhhdjbe6SegpRY7nDoDeVMH31O KMOFTJNp8rPncrHQIB69wbYLZvAhWwIjgY1+LoX2DZEwtj3Wt1lfgPMwhF4NwTUV dCJRMbK1/6zMewXGKKjHdsxjC4tFGyNlOxPnWgNA8H9jaCzJAl18jvsw2vNDzNlJ 1egOi41H+16w2LxQAYzd =+lTS -----END PGP SIGNATURE----- --qpi0JbQCMhe6tNKXjnKMHRcwHdrWogWin-- From nobody Wed May 14 23:38:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB46A1A03DC for ; Wed, 14 May 2014 23:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 984IyEWUsBBZ for ; Wed, 14 May 2014 23:38:48 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F394D1A03E3 for ; Wed, 14 May 2014 23:38:47 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so1001648qge.25 for ; Wed, 14 May 2014 23:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FQ5WfEl5tDrwhdNkmH60vceY29wG27ExEIC8xA/iE9I=; b=o/xp6aq8EEdrlHpLex0jeg1G+WY0hvhalXJ0DBg2hJfaaU773c0wwvbdohKyzT/iIr 7su7JHgu62WmmBZuMBf+JVVTvLPx3mvCHtR9qsKOZ3pyZro10nKcZntmyPm8O0lZh8Db E7pY2XGl9cC54xNqPdcNaoH/V6o5JLquJedjOVwA4DrAavKwZvnIA71HAoQzEYSjuyxx QVeZA1VWVL3P9rD2912s8GXx1VfOTQ0l+JHWcTmlSJaomcPnfRSZQYARIDMOyd9/GaR1 E4Q4LFKKCaeEOOiI9sw9npbAa6WIyTVjWOad1bhOd2E/n7QVv5Wp2bCwVPFXNGs0QD1p 7iyA== MIME-Version: 1.0 X-Received: by 10.140.92.37 with SMTP id a34mr11545718qge.91.1400135920672; Wed, 14 May 2014 23:38:40 -0700 (PDT) Received: by 10.140.107.161 with HTTP; Wed, 14 May 2014 23:38:40 -0700 (PDT) In-Reply-To: <04d201cf7007$1c24ced0$546e6c70$@huitema.net> References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> <04d201cf7007$1c24ced0$546e6c70$@huitema.net> Date: Wed, 14 May 2014 23:38:40 -0700 Message-ID: From: Robert Ransom To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UOvb9ii4gSCoQs2knfbBjYVaeB4 Cc: ietf tls Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 06:38:49 -0000 On 5/14/14, Christian Huitema wrote: >> If a comprehensive solution to the surveillance problem also involve > changes to >> plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the > solution >> depends on the DNS bits being deployed as well? > > This is a bit close to the "your side of the boat is leaking more than > mine" > argument. Let's plug both leaks, and not have each wait for the other. That's what Fabrice was suggesting. (Specifically: the pieces of text quoted in that message describe solutions to the TLS leaks which depend on having extra information pre-distributed in DNS.) Robert Ransom From nobody Thu May 15 01:36:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAAB1A0417 for ; Thu, 15 May 2014 01:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N42iC73i1RZF for ; Thu, 15 May 2014 01:36:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4DB1A0413 for ; Thu, 15 May 2014 01:36:26 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4F8aISN030499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 04:36:19 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4F8aGRX021906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 15 May 2014 04:36:18 -0400 Message-ID: <1400142976.15215.1.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Michael D'Errico" Date: Thu, 15 May 2014 10:36:16 +0200 In-Reply-To: <53745355.2010708@pobox.com> References: <53745355.2010708@pobox.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XVpViQMNBPWOXZnND9aT0HvyL3Y Cc: "tls@ietf.org" Subject: Re: [TLS] Simplify, simplify, simplify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 08:36:29 -0000 On Wed, 2014-05-14 at 22:40 -0700, Michael D'Errico wrote: > How do you get around the way version negotiation works? If a client > asks for TLS 1.3, and the server doesn't support it so it replies with > TLS 1.2, the client has to know how to speak 1.2. There's no way for > the client to say it supports TLS 1.0 and 1.3, but not 1.1 or 1.2. The best would be for TLS 1.3 not to bump the protocol version number. It could masquerade as TLS 1.2 and use extensions to negotiate any new functionality. That way it wouldn't have any interoperability issues (if we ignore for a moment the client hello size issues). regards, Nikos From nobody Thu May 15 03:14:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0E01A04A2 for ; Thu, 15 May 2014 03:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rl46GViyxPA for ; Thu, 15 May 2014 03:14:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE41A049E for ; Thu, 15 May 2014 03:14:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 59B30BE80 for ; Thu, 15 May 2014 11:14:32 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To6CP9Ntp9ks for ; Thu, 15 May 2014 11:14:32 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 358C6BE79 for ; Thu, 15 May 2014 11:14:32 +0100 (IST) Message-ID: <53749388.80009@cs.tcd.ie> Date: Thu, 15 May 2014 11:14:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <537448DD.7010806@accessnow.org> In-Reply-To: <537448DD.7010806@accessnow.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qNe3XbThdeyDQWb8gg0MmMHTT0g Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 10:14:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, One more thought for this thread before the meeting (for which I'll unfortunately be remote and distracted but I'm sure you'll have a good one). Considering tempora, which we know is happening, (so handshake bytes should be considered to be recorded with probability of approx. 1.0), even a simple hash of the SNI could have some limited value. Say if the client sent "hash-algId,H(tolower(SNI)||stuff)" or similar rather than sending just "SNI" (where "stuff" is maybe something to distinguish http vs imap perhaps). For the real server/router that's no deal at all assuming the router isn't dynamically routing to any old DNS name used in SNI. (Wouldn't that be a lovely DoS vector.) For the tempora attackers it'd mean they can no longer just do "select * from tempora_db where sni like %victim%" (pardon my SQL which is probably wrong;-) Now that might just be an irritant, and not that effective given the adversary can build up tables but I think it is an attack that we do need to specifically consider since we *know* the recording of those bytes is happening. And of course if we had a structure like "f-algId,f(SNI)" then other algs (e.g. encrypt with public key from DNS) could be added later if we can't use 'em now, so even adding this minimal bit of "protection" might provide the right hooks for later, better work. A workable SNI encryption scheme is of course what we'd like, and would blow the above out of the water, but if we don't find a workable SNI encryption scheme now, there might be reasons to think about the structure above and there are definite reasons to think about tempora as an attack. Cheers, S. PS: To be clear, I'm more arguing for considering the tempora attack here and maybe for the structure and am not really a fan of a simple hash. And #include as usual. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTdJOIAAoJEC88hzaAX42iW/QH/jDJ3ggmqFv74vh34p46UPyJ 35Ztq31db6DYA70ianiXdEi1+w1QJVTaGymeff3wCaEQgpPEvaCOR1itJEMNAuoe WlaJjWCOqougL6fMpLgpt4bruGs07kEnw6LJPCAGzyCb2sZ2cyyrdf/euPAcq0DD YDN1BRwhRx/EHPuWHWxFS+m9fGMefJml6VkenFEUi0DIcseb7SOSbxeU/Ywe22uE uGo/lKLip7obsmLCSECdldMuqPvA+Fa4r1lAed3Qx6ApwCUnqoZVxwPc1FoxfNwj 7A8hiw6bFpe5PmSzwfN9AxZch/FnkajzDEy8+Lm9hMZGnLWn2jxpRMk9Q/lW5a8= =nhuj -----END PGP SIGNATURE----- From nobody Thu May 15 07:00:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D227D1A04E9 for ; Thu, 15 May 2014 07:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTYPE_001C_B=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMzIwYiDwTKI for ; Thu, 15 May 2014 07:00:15 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7EF1A00B7 for ; Thu, 15 May 2014 07:00:15 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 15 May 2014 10:00:03 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Thu, 15 May 2014 10:00:03 -0400 From: Dan Brown To: "'stephen.farrell@cs.tcd.ie'" , "'tls@ietf.org'" Thread-Topic: [TLS] In support of encrypting SNI -- does IBE help with this problem? Thread-Index: Ac9wRfKvlIZIZa/lToeLf+3Df4RxbA== Date: Thu, 15 May 2014 14:00:03 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C829F1@XMB116CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CF7024.708FF590" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mcPRYUK7y-FPizt8cas2y-L1ioA Subject: Re: [TLS] In support of encrypting SNI -- does IBE help with this problem? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 14:00:24 -0000 ------=_NextPart_000_0000_01CF7024.708FF590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is using an ID-based encryption a possibility here? I haven't tracked this thread too closely, so I apologize if the TLS list has already hashed through this idea. (E.g. maybe this is too unconventional, etc.). Anyway, in case you are still interested, here's one theoretical way it might work, with pairing-based elliptic curve (with <.,.> operation): Public values G generator N server name (hashed into group) T trusted authority public key C client ephemeral public key Private keys c client ephemeral private r client random key t trusted authority private n server name private Key pair relationships (additive elliptic curve notation aB, ranslate to B^a if you prefer that notation) C = cG T = tG n = tN To recap, the goal is that the server support multiple private-public key pairs (n,N), the client can convey the choice of N to the server, without revealing N to third parties. Client compute U = Hash() where <,> is the pairing operation. Client -> server: C, U Server: For each n compute V = Hash (), until V=U. Now server has determined N and continues with rest of handshake, using more conventional crypto. Of course, trusted authority can also determine N, so as usual distributed across several entities. Another downside would be the large overhead for the server who supports many N. Even one N might dominate the cost of the handshake. Also, I'm not an expert in pairing based crypto, so I'm only really guessing the IBE has the desired anonymity properties. (That's why I applied the hash.) To my non-expert eye, it seems the client chooses an N that the server does not support, this is not leaked to the server. Also, the server does not reveal the set of N that it supports to the client, just the N that the client wants. I suppose that U could also be encrypted with an unauthenticated agreed key, if it is set after the client receives the server ephemeral public key. Just a thought, Best regards, Dan > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Thursday, May 15, 2014 6:15 AM > To: tls@ietf.org > Subject: Re: [TLS] In support of encrypting SNI > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hiya, > > One more thought for this thread before the meeting (for which I'll > unfortunately be remote and distracted but I'm sure you'll have a good one). > > Considering tempora, which we know is happening, (so handshake bytes should > be considered to be recorded with probability of approx. 1.0), even a simple > hash of the SNI could have some limited value. > > Say if the client sent "hash-algId,H(tolower(SNI)||stuff)" > or similar rather than sending just "SNI" (where "stuff" > is maybe something to distinguish http vs imap perhaps). > > For the real server/router that's no deal at all assuming the router isn't > dynamically routing to any old DNS name used in SNI. (Wouldn't that be a lovely > DoS vector.) > > For the tempora attackers it'd mean they can no longer just do "select * from > tempora_db where sni like %victim%" (pardon my SQL which is probably wrong;- > ) > > Now that might just be an irritant, and not that effective given the adversary can > build up tables but I think it is an attack that we do need to specifically consider > since we *know* the recording of those bytes is happening. > > And of course if we had a structure like "f-algId,f(SNI)" > then other algs (e.g. encrypt with public key from DNS) could be added later if > we can't use 'em now, so even adding this minimal bit of "protection" might > provide the right hooks for later, better work. > > A workable SNI encryption scheme is of course what we'd like, and would blow > the above out of the water, but if we don't find a workable SNI encryption > scheme now, there might be reasons to think about the structure above and > there are definite reasons to think about tempora as an attack. > > Cheers, > S. > > PS: To be clear, I'm more arguing for considering the tempora attack here and > maybe for the structure and am not really a fan of a simple hash. > And #include as usual. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJTdJOIAAoJEC88hzaAX42iW/QH/jDJ3ggmqFv74vh34p46UPyJ > 35Ztq31db6DYA70ianiXdEi1+w1QJVTaGymeff3wCaEQgpPEvaCOR1itJEMNAuoe > WlaJjWCOqougL6fMpLgpt4bruGs07kEnw6LJPCAGzyCb2sZ2cyyrdf/euPAcq0DD > YDN1BRwhRx/EHPuWHWxFS+m9fGMefJml6VkenFEUi0DIcseb7SOSbxeU/Ywe22 > uE > uGo/lKLip7obsmLCSECdldMuqPvA+Fa4r1lAed3Qx6ApwCUnqoZVxwPc1FoxfNwj > 7A8hiw6bFpe5PmSzwfN9AxZch/FnkajzDEy8+Lm9hMZGnLWn2jxpRMk9Q/lW5a8 > = > =nhuj > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0000_01CF7024.708FF590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUxNTE0MDAwMlowIwYJKoZIhvcNAQkEMRYEFF+F OeDOKbICl+UEu9CC+b27v1saMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYA8Dk7RXdNF/YuW2dYEbtMCgXV91ECr EZLCyX28HG30i1xCYpvwTWKU0axlEwz4Cdlb241TqYPJxXGzjYMByqQ3p6nX5FkPZUg8E+SvpPBk RgHLCGWiiv3sJFGR6CydjZ684YzeIdY+5e9xQ5s2CqnC6l9gM+HMY60GOu9EF2cvTgAAAAAAAA== ------=_NextPart_000_0000_01CF7024.708FF590-- From nobody Thu May 15 08:05:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E101A02A5 for ; Thu, 15 May 2014 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtgdpknAlOxI for ; Thu, 15 May 2014 08:05:51 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 974EF1A029B for ; Thu, 15 May 2014 08:05:51 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 53E3D4820D; Thu, 15 May 2014 15:05:44 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 47E57481DB; Thu, 15 May 2014 15:05:44 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 20BDC1E041; Thu, 15 May 2014 15:05:44 +0000 (GMT) Received: from Tereva.local (172.19.115.218) by USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 15 May 2014 11:05:43 -0400 From: Brian Sniffen To: Marsh Ray , David Holmes , Eric Rescorla In-Reply-To: <15d5a50ed2244e8595edfa57d7055e2b@BY2PR03MB554.namprd03.prod.outlook.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> <15d5a50ed2244e8595edfa57d7055e2b@BY2PR03MB554.namprd03.prod.outlook.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Thu, 15 May 2014 09:05:45 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-owI5UTShjbCdyw2njJnSXoTtIk Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:05:53 -0000 Marsh Ray writes: > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Brian Sniffen >> >> Bitcoin's also hard to check: if the client says it found no bitcoin in a >> particular region, how do you know? And a whole bitcoin's too >> much to ask. >> >> An identity scheme tied to giving away bitcoin---much like a credit >> rating ties to many transactions profitable for the counterparty--- >> has a lot in its favor. It would make a great (research) extension >> on top of TLS 1.3, and I hope that any puzzle mechanism will be >> flexible enough to support that. > > Years back, Microsoft was looking into a proof-of-work scheme for antispam sender-pays email. > http://research.microsoft.com/en-us/projects/pennyblack/ Thanks! I hadn't remembered the name, but that work was surely on my mind as I wrote. > One challenge is that botnets (that are conduits for most of the spam) also have plenty of spare CPU capacity. Yes, but each bad node's CPU capacity only outstrips many good node's capacities by a little bit---compared to network bandwidth, where very often botnets outstrip good nodes' capacity by orders of magnitude. Of course the bad nodes will beat out cell phone CPUs; a client puzzle scheme has to be about, in some part, "acceptable losses." If we can drop new mobile nodes and the botnet, but keep service up for (say) established connections and "real" computers, that may be okay. -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Thu May 15 14:50:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4851A014B for ; Thu, 15 May 2014 14:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOdkzsvWQKnl for ; Thu, 15 May 2014 14:50:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969161A0144 for ; Thu, 15 May 2014 14:50:34 -0700 (PDT) Received: from BY2PR03MB554.namprd03.prod.outlook.com (10.141.141.156) by BY2PR03MB555.namprd03.prod.outlook.com (10.141.141.27) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 15 May 2014 21:50:25 +0000 Received: from BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) by BY2PR03MB554.namprd03.prod.outlook.com ([10.141.141.156]) with mapi id 15.00.0939.000; Thu, 15 May 2014 21:50:25 +0000 From: Marsh Ray To: "tls@ietf.org" Thread-Topic: [TLS] In support of encrypting SNI Thread-Index: AQHPb/n1N51p6bJHgkerv5ryJDuvgptBbPkAgAC+D7A= Date: Thu, 15 May 2014 21:50:24 +0000 Message-ID: References: <537448DD.7010806@accessnow.org> <53749388.80009@cs.tcd.ie> In-Reply-To: <53749388.80009@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(85852003)(83072002)(101416001)(15202345003)(86612001)(15188555004)(92566001)(86362001)(87936001)(15975445006)(19580395003)(4396001)(2656002)(76576001)(77096999)(83322001)(54356999)(99396002)(99286001)(76176999)(50986999)(79102001)(74316001)(77982001)(76482001)(21056001)(33646001)(561944003)(31966008)(74502001)(81342001)(74662001)(81542001)(46102001)(64706001)(20776003)(80022001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB555; H:BY2PR03MB554.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=maray@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Yge5H7t_vSTi7PeV-0H0nNOpsYk Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 21:50:37 -0000 From: Stephen Farrell http://www.ietf.org/mail-archive/web/tls/current/msg08722.html > A workable SNI encryption scheme is of course what we'd like,=20 > and would blow the above out of the water, but if we don't find > a workable SNI encryption scheme now, there might be reasons > to think about the structure above and there are definite > reasons to think about tempora as an attack. Dan Blah writes: > Many of the discussions and subsequent decisions that move forward=20 > here are incredibly important to OTF's work. As such, I wanted to toss=20 > in our support for the coming version of TLS 1.3 to "Encrypt as much=20 > of the handshake as possible". This should include all of the metadata=20 > and TLS-layer routing information. We think by default is important=20 > for those threatened users we work closely with. From: Nikos Mavrogiannopoulos > The best would be for TLS 1.3 not to bump the protocol version number. > It could masquerade as TLS 1.2 and use extensions to negotiate any new > functionality. That way it wouldn't have any interoperability issues > (if we ignore for a moment the client hello size issues). Apologies to those who have heard this before, but I lose stuff in the volu= me. A couple of years back I made a detailed proposal precisely for encrypting "as much of the handshake as possible" (including SNI) using TLS 1.0-compatible extensions: http://tools.ietf.org/id/draft-ray-tls-encrypted-handshake-00.txt This specification defines a Transport Layer Security (TLS) extension which allows endpoints to negotiate the use of encryption with forward secrecy at the beginning of the handshake. Two levels of functionality are defined. Implementations are free to support one or both levels, with the first level incurring no additional computational or round-trip overhead. The TLS cryptographic calculations are unchanged. The Introduction section describes my then-current thinking on the topic. The ensuing list discussion felt productive: http://www.ietf.org/mail-archive/web/tls/current/msg08722.html - Marsh --------------- Boilerplate disclaimers apply. From nobody Thu May 15 20:32:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ADF1A00A8 for ; Thu, 15 May 2014 20:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFHvqIaRulbi for ; Thu, 15 May 2014 20:32:55 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3DA1A007E for ; Thu, 15 May 2014 20:32:55 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id v1so3886391yhn.16 for ; Thu, 15 May 2014 20:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2uH7q1YZFFVW58D8Hk69tQQdg6MUVHIyU62A9dYrMkk=; b=cHftxCRgsvSv0PndMxJwDR9rOPTlFAXda+DL9d1GsRK79jwsrdmq40C8bQ3fcW9dXs YwAmXafUQWkwRux9aK2IeXiNFmnF6uhZWx7Clvw8F4xZnUnRtm3uh8SzacybqehJevsO PnPlnidLr5+jUOJqrB8BdHGZ4HdXLFXD6fvooYlYM++epiaVZ4PInDXSlYML6ay/QvPW xhxOA5x0LMvS0WLHdILBHg0fxXGJw9gGJ36uA/oXPJo4R7+7q+ustbX69B2vT8+ErnyS H/E/W6zi4TaCnDj4P8qwVpb4DlG7ZJ2qb74Uf89wSfN4qqTBo7iWyB1Hm5gtpGP4nF1I bGFg== MIME-Version: 1.0 X-Received: by 10.236.39.72 with SMTP id c48mr21447471yhb.89.1400211167929; Thu, 15 May 2014 20:32:47 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 15 May 2014 20:32:47 -0700 (PDT) In-Reply-To: References: <5373C4F3.3010602@blah.is> <5373d656.84c5440a.1a9b.25a0SMTPIN_ADDED_BROKEN@mx.google.com> <498BFB9F-EF8D-48E2-92A9-4287491FB9B7@gmail.com> <04d201cf7007$1c24ced0$546e6c70$@huitema.net> Date: Thu, 15 May 2014 20:32:47 -0700 Message-ID: From: Watson Ladd To: Robert Ransom Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AKuCC6EIKI_X6_rbD4n-jRpS214 Cc: ietf tls Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 03:32:57 -0000 On Wed, May 14, 2014 at 11:38 PM, Robert Ransom wrote: > On 5/14/14, Christian Huitema wrote: >>> If a comprehensive solution to the surveillance problem also involve >> changes to >>> plug leaks by DNS, wouldn't it be reasonable that the TLS portion of the >> solution >>> depends on the DNS bits being deployed as well? >> >> This is a bit close to the "your side of the boat is leaking more than >> mine" >> argument. Let's plug both leaks, and not have each wait for the other. > > That's what Fabrice was suggesting. (Specifically: the pieces of text > quoted in that message describe solutions to the TLS leaks which > depend on having extra information pre-distributed in DNS.) It's a little more subtle than that. Options 3 and 1 have the same security absent DNSSEC, but different performance, with Option 1 requiring an extra round trip. However, Option 3 requires administrative action on the part of a website to work. The payoff depends on DNSSEC. So right now I see Option 1 or 3 as our best bet, with very limited real world impact. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu May 15 21:38:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2D1A0112 for ; Thu, 15 May 2014 21:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVI9g0caoLD2 for ; Thu, 15 May 2014 21:38:14 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F801A010C for ; Thu, 15 May 2014 21:38:14 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4G4c1gD028317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 May 2014 06:38:01 +0200 (MEST) In-Reply-To: <53749388.80009@cs.tcd.ie> To: Stephen Farrell Date: Fri, 16 May 2014 06:38:01 +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: <20140516043801.C2FCF1AD06@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2WeVbSDvKFn4EXZlK07LNXqfsqU Cc: tls@ietf.org Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 04:38:16 -0000 Stephen Farrell wrote: > > Say if the client sent "hash-algId,H(tolower(SNI)||stuff)" > or similar rather than sending just "SNI" (where "stuff" > is maybe something to distinguish http vs imap perhaps). The underlying idea is in principle correct: if the client does not want to disclose the server's hostname, then the client plain and simple MUST NOT send that hostname in TLS extension SNI. It is conceivable that the client could send something else instead, that the server could use for dispatching the TLS session to the correct virtual host (independent of whether that is physicial or logical routing of the TLS session). > > And of course if we had a structure like "f-algId,f(SNI)" > then other algs (e.g. encrypt with public key from DNS) > could be added later if we can't use 'em now, so even > adding this minimal bit of "protection" might provide > the right hooks for later, better work. While something like publishing an RSA public key in DNS and using an encryption transform with random padding (PKCS#1 BT02 or OAEP) could provide the functionality, this would also significantly increase the server's workload (make TLSv1.3 session resumes as expensive as TLSv1.2 static RSA full handshakes) and make the key management (the rollover) a magnitude more difficult from what it is now (not counting the accompanying code complexity). If the whole SNI-hiding scheme would depend on the necessary key being available in the DNS, then those servers that have only a single server credential or that need high performance could avoid the entire bloat, and that would be the most important aspect of this. Personally, I consider pretty much all of the ideas that have been floated so far, to be magnitudes of complexity beyond what I could risk shipping to our customers from the usability viewpoint. TLS key management is already the number one support issue today, and the first customers started suffering from server load when moving from RSA-1024 to RSA-2048 (even for static RSA key exchanges) when there were problems with TLS session caching on TLS clients. For our current TLS implementation, I can update&replace the server credential (key,cert and cert chain) as well as trust anchors for the verification of client certs in "full flight" (i.e. zero downtime), but for multiple server keys distributed through different protocols (DNS OOB plus TLS inband), I can not even conceive a robust / zero downtime key management and key rollover. Actually, I'm much more worried about the services on the internet today that still do not use TLS at all (many discussion forums, online shops and places like ebay), and I have exactly ZERO problem doing online banking over TLS with static-RSA and RC4-128 or TLSv1.0 and CBC. And I'm somewhat worried that making TLS more complex, administration more difficult, troubleshooting harder and performance impact worse is going to further deter adoption of TLS by the large unwashed masses of today's HTTP-in-the-clear usage scenarios, similar to how feature bloat, complexity, and poor usability still deters deployment of IPv6 today. -Martin From nobody Thu May 15 22:19:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC4E1A011D for ; Thu, 15 May 2014 22:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPdfbfBQkNhg for ; Thu, 15 May 2014 22:19:51 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019EA1A011C for ; Thu, 15 May 2014 22:19:50 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so1747636ykp.6 for ; Thu, 15 May 2014 22:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L6SrVUpTirjUNp3fcr8Fe5ZuqV+9ZzkVJSqzIl3V+z8=; b=Tb0ZAyCr36YZsYSm/ZmDDMQBmslBgsKLIHplh9ZT89L/bkSk8wQCVVb9NPG1ctaJQO nGaLNpu6wmvlzmrfRjoZvdByU7s9sS/X9eoayeedlhUuWoIYO8ZGBY061XoP/SAb4F6V bX7EriwNy/O2nIiXvUmUXziDq6eEBeQt8EuEdax5F6+9o/wkkc0+wBEY6lMjhOnDglEr Jvftsq0LncLlHbbdl3T9zZNsPOAvKs255SkvwbK10gL+z6E9N02Fnr0VRAKofclpOQ0w 8nOjZ2/0dbsAShneEFFLsTGO38mjBxJtERSyMeyz3E3yvm1pNSl+vxhJikD6K4AO6ecb rp5A== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr21976250yhj.63.1400217583194; Thu, 15 May 2014 22:19:43 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 15 May 2014 22:19:43 -0700 (PDT) In-Reply-To: <20140516043801.C2FCF1AD06@ld9781.wdf.sap.corp> References: <53749388.80009@cs.tcd.ie> <20140516043801.C2FCF1AD06@ld9781.wdf.sap.corp> Date: Thu, 15 May 2014 22:19:43 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_zdCbkkYcpogklp4ECg7S4hhiIU Cc: "tls@ietf.org" Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 05:19:53 -0000 On Thu, May 15, 2014 at 9:38 PM, Martin Rex wrote: > Stephen Farrell wrote: >> >> Say if the client sent "hash-algId,H(tolower(SNI)||stuff)" >> or similar rather than sending just "SNI" (where "stuff" >> is maybe something to distinguish http vs imap perhaps). > > The underlying idea is in principle correct: > if the client does not want to disclose the server's hostname, then the > client plain and simple MUST NOT send that hostname in TLS extension SNI. > > It is conceivable that the client could send something else instead, > that the server could use for dispatching the TLS session to the > correct virtual host (independent of whether that is physicial or > logical routing of the TLS session). > > >> >> And of course if we had a structure like "f-algId,f(SNI)" >> then other algs (e.g. encrypt with public key from DNS) >> could be added later if we can't use 'em now, so even >> adding this minimal bit of "protection" might provide >> the right hooks for later, better work. > > While something like publishing an RSA public key in DNS and > using an encryption transform with random padding (PKCS#1 BT02 or OAEP) > could provide the functionality, this would also significantly > increase the server's workload (make TLSv1.3 session resumes as > expensive as TLSv1.2 static RSA full handshakes) and make the > key management (the rollover) a magnitude more difficult from > what it is now (not counting the accompanying code complexity). > There are proposals out there (DH channel, authentication through signing shared key) that require the server to do two exponentiations, at the cost of multiple round trips. That's more performant in CPU time than RSA-2048, and doesn't involve DNS keys. (Yes, I'm aware most people don't use ECDSA: but why moan about speed when you haven't already used the fastest option there is?). Furthermore, many of the proposed changes in TLS 1.3 reduce complexity: one padding scheme instead of three, dramatically reduced numbers of allowed flows, obviate the need for secure renegotiation by fixing the underlying problem, eliminate ciphers whose security has been called into question, remove some little-used certificate options, and hopefully simplify administration even further. If you want simplicity CurveCP can be implemented in ~1,00 lines of C+100*140 characters of underlying crypto. It has similar security properties to the handshakes were are discussing now, and much more performance. I share your concern about ubiquity in HTTP: that's being fixed with opportunistic HTTPS/not popping up a great big warning sign for self-signed certificates. I don't think protocol complexity is what's holding back deployment today so much as the cost of certificates (which DANE addresses) and the complexity and hassle of management of keys. Sincerely, Watson Ladd > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri May 16 05:33:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5F41A022B for ; Fri, 16 May 2014 05:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbRbp6NxRwRb for ; Fri, 16 May 2014 05:33:48 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1581A021F for ; Fri, 16 May 2014 05:33:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 21C6A2AB116; Fri, 16 May 2014 12:33:39 +0000 (UTC) Date: Fri, 16 May 2014 12:33:39 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140516123339.GW27883@mournblade.imrryr.org> References: <536977E3.3000608@akr.io> <20140507002452.GH27883@mournblade.imrryr.org> <20140507020023.GI27883@mournblade.imrryr.org> <20140507035957.GM27883@mournblade.imrryr.org> <20140507055835.GN27883@mournblade.imrryr.org> <20140514022221.GE27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ehIqX9TAO4uPLP4eusosY2jnCBo Subject: Re: [TLS] The risk of misconfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 12:33:50 -0000 On Tue, May 13, 2014 at 08:06:08PM -0700, Watson Ladd wrote: > > It is perhaps time to retire the belief that TLS for email is in > > a "sad state". Of course it would be nice to also have authentication, > > but for that we need DNSSEC deployment and publication of TLSA RRs. > > So 0% of the email is actually protected from being read by anyone on > the network. (well, modulo PGP). In another 20 years we might have a > solution deployed. You have an odd definition of "protected". Protection of content from passive monitoring is not an insignificant benefit. In the mean-time a second German email provider has enabled DANE (two this week), so now all posteo.de deliveries to mailbox.org are authenticated. While that may be "0%" overall, it is not 0% for posteo.de. > And for this you want to run the risk of using aDH? Deja vu all over again. (No the reasons is to not destroy TLS as a transport for channel-binding + application-level authentication, the fact that Postfix offers and accepts aDH in opportunistic mode is rather secondary, and we've already had this discussion...). -- Viktor. From nobody Fri May 16 11:28:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8641A00F1 for ; Fri, 16 May 2014 10:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dJGLwgulsDl for ; Fri, 16 May 2014 10:57:26 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE961A0149 for ; Fri, 16 May 2014 10:57:26 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lg15so6542414vcb.7 for ; Fri, 16 May 2014 10:57:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=h0C1PS1ErcrgmMok74MBVwsv+cPG1LVmKDZtZaabGGw=; b=WviU5riZHzuGzIV1VzKl24L3Yl78UPGpXLLOjfkpQB/KOVqYu6bxsv/dTEyROL9DyZ zzO61t1EoqHv9JJwCaSA6a/WaL8v0367FRkyEGFlZFwVM/OBrFU4lVD/rXuh+0Sdu/z1 UgEu1vGEz+NPjJnx7xnCsQjM1a7yDJ9LO+D80dBXbJ+IoSvPmH8ICGLpJbU3qHRxZMZ6 AzZ0u1Bp25VLuGOuch9HCw21zJSI8KR1vIdau2bRwMRq0phPL0djdhlJOsuTJrCi6LvQ AYBVs20DlbwVSBusFC1yNujPsv6UnGYJ+tA7mL1fOULmSLWB+QUUazKTYy9q5vG6zFPb ER0g== X-Gm-Message-State: ALoCoQmYBPgM7PWUr7lrGiYbM680yLgxCSjqAcbS3jXsZ1muB/+7vtIaVdzX1pM9Ae6kTnRfpMt5 X-Received: by 10.58.96.36 with SMTP id dp4mr2159444veb.21.1400263038135; Fri, 16 May 2014 10:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.246.39 with HTTP; Fri, 16 May 2014 10:56:57 -0700 (PDT) From: Andy Lutomirski Date: Fri, 16 May 2014 10:56:57 -0700 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0g0xzzSbDyDenE2Uh02_ertro9g Subject: [TLS] Very rough proposal for QUIC-ish SNI-encryption-compatible flow X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 17:57:28 -0000 Here's my rough proposed flow. This have the property that all TLS 1.3 successful connections have exactly the same set of messages exchanged and the same kind of transcript. This may make this a lot easier to understand. A successful TLS 1.3 connection attempt looks like: ClientHello Cleartext extensions KeyID [may be 0 for plaintext] MaskSessionKey [starts blank] Masked { ClientHello SNI Encrypted server hello keying material Server mask key [same cipher as for KeyID, but w/o DH] DH share, Client Random, Ciphersuites, Enxrypted extensions } ServerHello ServerMaskPolicy Masked { ServerSupportedGroups Server random, cert, etc. [or "wrong DH group", try again] } This can restart for three reasons: 1. The mask id is some special flag that asks the server for a valid ServerMaskPolicy. 2. The server hello keying material was on the wrong group. The server should send ServerMaskPolicy, which must include a list of acceptable groups for the server hello keying material. (It can suggest sending SNI in the clear.) 3. The client's DH share was on the wrong group. The server should reply with ServerSupportedGroups. Handshake restarts clear all state, except that, after a restart, clients must verify that ServerMaskPolicy and ServerSupportedGroups (depending on where the restart was) are exactly what the client expected. This is critical to prevent downgrade. Notes: The server hello encryption group is in ServerMaskPolicy because, in the event of a failure to encrypt the server hello, the server can't safely send ServerSupportedGroups without weaking SNI encryption. This needs to be massaged into a state in which the unmasked case will allow TLS 1.2 and below servers to handshake. This may be easy. ServerSupportedGroups are a lot like PredictedParameters. ServerMaskPolicy is a list of valid DANISH B-style associations. It may be acceptable for the client's DH shares to be identical. A real cryptographer should confirm. We could require this in the unencrypted SNI case (i.e. require the client to choose the same share and group when possible) to avoid allowing a client to force a server to do an extra DH computation. --Andy From nobody Fri May 16 12:57:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7B1A0338 for ; Fri, 16 May 2014 12:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gfYkNLpcM8v for ; Fri, 16 May 2014 12:57:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2901A0208 for ; Fri, 16 May 2014 12:57:39 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s4GJvQOf028778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 May 2014 21:57:26 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Fri, 16 May 2014 21:57:26 +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: <20140516195726.5E6451AD07@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E8TszH_aT0064p09Cms2A_1OsqA Cc: "tls@ietf.org" Subject: Re: [TLS] In support of encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 19:57:42 -0000 Watson Ladd wrote: > Martin Rex wrote: >> >> While something like publishing an RSA public key in DNS and >> using an encryption transform with random padding (PKCS#1 BT02 or OAEP) >> could provide the functionality, this would also significantly >> increase the server's workload (make TLSv1.3 session resumes as >> expensive as TLSv1.2 static RSA full handshakes) and make the >> key management (the rollover) a magnitude more difficult from >> what it is now (not counting the accompanying code complexity). > > There are proposals out there (DH channel, authentication through > signing shared key) that require the server to do two exponentiations, > at the cost of multiple round trips. That's more performant in CPU > time than RSA-2048, and doesn't involve DNS keys. (Yes, I'm aware most > people don't use ECDSA: but why moan about speed when you haven't > already used the fastest option there is?). I believe we're talking past each other here. On a healthy TLS server, the ration of abbreviated TLS handshakes vs full TLS handshakes is around 50:1. The abbreviated TLS v1.[012] handshake is entirely *FREE* of public key crypto, and the ClientHello on a new connection that offers the abbreviated TLS handshake carries in the clear *ALL* information necessary for routing the TLS session and for performing a full TLS handshake in case that session resumption might not possible. Public Key crypto on abbreviated TLS handshakes would make TLS prohibitively expensive for many/most large server installations of our customers. > > Furthermore, many of the proposed changes in TLS 1.3 reduce > complexity: one padding scheme instead of three, The only thing that reduces complexity is complete removal of options, and even then this just applies to the specification itself. For an implementation, you can not seriously expect interop without implementing all of TLSv1.0 through TLSv1.2 in addition to TLSv1.3, so even removal of an existing option adds code. New features or changing exiting options will increase complexity of implementations and cause interop failures in the installed base due to a lack of of testing (cartesian explosion). One large vendor botched the RSA premaster secret version check when starting to ship TLSv1.2 support. A problem that would have been obvious and impossible to miss for a single engineer in pure black-box testing with _his_own_ shelf clients and servers within 15 minutes. > > If you want simplicity CurveCP can be implemented in ~1,00 lines of > C+100*140 characters of underlying crypto. It has similar security > properties to the handshakes were are discussing now, and much more > performance. Someone who talks about new crypto, and projects effort in terms of Lines-of-Code, may not have to deal with issues like FIPS 140-2... > > I share your concern about ubiquity in HTTP: that's being fixed with > opportunistic HTTPS/not popping up a great big warning sign for > self-signed certificates. I don't think protocol complexity is what's > holding back deployment today so much as the cost of certificates > (which DANE addresses) and the complexity and hassle of management of > keys. The reason that many discussion forums, online shops and ebay do not use https today is probably _not_ the browser/client side, but getting the server-side (setup,admin,maintenance) work, i.e. - key&trust management - key continuity & rollover - PKIX bureaucracy and (lack of) interop fun -Martin From nobody Sat May 17 09:29:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA341A0166 for ; Sat, 17 May 2014 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu8L7S4R-EN9 for ; Sat, 17 May 2014 09:29:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53A1A0160 for ; Sat, 17 May 2014 09:29:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4HGTI1q009202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 May 2014 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400344182; bh=Wh4WMuKElVJRoU9frw/w+ttQbw6/f35eqDer5Az9U5U=; h=Date:To:From:Subject:In-Reply-To:References; b=F9M/JcGmVkgkMwLvXDzXr2PxkA2uaqpD15Vj8adyZF9jQAkKkDP0tCPT9NpojfpCN nbls2qO1mP1Rx0OOXTIGo6rBJS+hk02x/tCgbb/8MqOk8oI+rpzc3DqFz8cz/S+pcK kpvHlXsYwtHikrirWdG30V2W62lwYIFk+DKz9C9c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1400344182; i=@elandsys.com; bh=Wh4WMuKElVJRoU9frw/w+ttQbw6/f35eqDer5Az9U5U=; h=Date:To:From:Subject:In-Reply-To:References; b=nF/rt/EO7aAZsDPdDjuvVy0VmBmhc9Jrb/Xnk6q6AGtTZ2vVoF2zBfsXdzXVgzzOk YZNYa85q2D2LMaRMdZodsoDtEVtUYuxpnbIpoXdJQ+cOp3HFdY6P47m9FvRCIW9NFG EpncAGd4QkcCBlf6HEFUhQcxDH9paWg3edjvNdJw= Message-Id: <6.2.5.6.2.20140517075513.0bc6bfa8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 17 May 2014 08:15:35 -0700 To: Dan Blah , tls@ietf.org, Michael Carbone From: S Moonesamy In-Reply-To: <5373C4F3.3010602@blah.is> References: <5373C4F3.3010602@blah.is> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Yiw1Us8sKrDcUqeVzisFKKlXNUI Subject: Re: [TLS] In support of encrypting SNI (off-topic) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 16:29:57 -0000 Hi Dan, Michael, At 12:33 14-05-2014, Dan Blah wrote: >I'm writing in both my personal and professional capacity as managing >director of the Open Technology Fund. We offer direct and in-kind >support to global individuals and organizations confronting the many >threats to Internet freedom globally. It's likely you're familiar with The message is from blah.is. I cannot determine whether there is any association with the "Open Technology Fund". >Even those all addressed, in some situations we will fall short of >aggressive censors. Despite that, it's a start, it's forward movement, >and omitting these features in TLS 1.3 will make it that much easier for >censors to silence the voice of journalists, human rights defenders, >NGOs, activists, and bloggers around the world. The above seems like a political matter [1]. At 21:55 14-05-2014, Michael Carbone wrote: >We hope the IETF considers the needs of at-risk users as well as of all >of us targeted by pervasive monitoring in supporting encrypted TLS >handshakes by default. It would be safer for the at-risk users if they ensured that those needs are taken into account in the final version of the relevant specification. Regards, S. Moonesamy 1. It could be argued that leaking the information should be considered as part of the (IETF) security considerations. From nobody Sat May 17 12:55:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8091A01F6 for ; Sat, 17 May 2014 12:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_FSL_HELO_BARE_IP_2=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL-sZ-EMachI for ; Sat, 17 May 2014 12:55:15 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD59B1A01E7 for ; Sat, 17 May 2014 12:55:14 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id i8so6534870qcq.18 for ; Sat, 17 May 2014 12:55:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type; bh=ta+Eg48bIzp2yqsKSy8eT7csKduwJnhFV8R1wDO2glU=; b=J35c4MVLDXlacctCEK31q8YNbjfvejCdkm6klUdwS19UK06vkDVaaxQV4MxFSTZ2j9 Xj/L/rscci4Bvd8w5SqyNeltL2IexetZuqqKOscUbVrOpQ3C75igAe8JpZ7H7+PlfGy/ Aw98oToxzvNsqkp3b5LE/jm1m90gDfaHsXxCoD+mZRIfyn7Kj9Iz2yVQ9CCuIhuYchtG 4mom1xdAekxr49feSi5Qq/1SCAV2aiu4EoAw2d7D7w4Q1V3TUArXRbHd7t+j4L8LJcim znS4eu+MWEVrK8Zi9sg4iFzz1v8bO8OXcHsvaVrI9UbwFES20cqevpohEPCj8Fo4eHvr X+uA== X-Gm-Message-State: ALoCoQnwJe6qHJUR1NTN2IG6U9UrAVRUuPXQpUOBO45rhNLFXDK+eWlDbZ/Ox5fydvgYzeBnlGay X-Received: by 10.140.93.2 with SMTP id c2mr31534673qge.53.1400356513872; Sat, 17 May 2014 12:55:13 -0700 (PDT) Received: from 127.0.0.1 (tor-node.rutgers.edu. [128.6.224.107]) by mx.google.com with ESMTPSA id o16sm19188838qax.23.2014.05.17.12.55.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 12:55:13 -0700 (PDT) Message-ID: <5377BE89.6000807@accessnow.org> Date: Sat, 17 May 2014 15:54:49 -0400 From: Michael Carbone MIME-Version: 1.0 To: tls@ietf.org References: <5373C4F3.3010602@blah.is> <6.2.5.6.2.20140517075513.0bc6bfa8@resistor.net> In-Reply-To: <6.2.5.6.2.20140517075513.0bc6bfa8@resistor.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9wT5eVSCHBiHjFoR588fn13rOBT6Txr4P" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O8Q1mpCoMssBALkB2RwWJBVr7NI Subject: Re: [TLS] In support of encrypting SNI (off-topic) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 19:55:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9wT5eVSCHBiHjFoR588fn13rOBT6Txr4P Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable S Moonesamy: > Hi Dan, Michael, > At 12:33 14-05-2014, Dan Blah wrote: >> I'm writing in both my personal and professional capacity as managing >> director of the Open Technology Fund. We offer direct and in-kind >> support to global individuals and organizations confronting the many >> threats to Internet freedom globally. It's likely you're familiar with= >=20 > The message is from blah.is. I cannot determine whether there is any > association with the "Open Technology Fund". >=20 >> Even those all addressed, in some situations we will fall short of >> aggressive censors. Despite that, it's a start, it's forward movement,= >> and omitting these features in TLS 1.3 will make it that much easier f= or >> censors to silence the voice of journalists, human rights defenders, >> NGOs, activists, and bloggers around the world. >=20 > The above seems like a political matter [1]. >=20 > At 21:55 14-05-2014, Michael Carbone wrote: >> We hope the IETF considers the needs of at-risk users as well as of al= l >> of us targeted by pervasive monitoring in supporting encrypted TLS >> handshakes by default. >=20 > It would be safer for the at-risk users if they ensured that those need= s > are taken into account in the final version of the relevant specificati= on. >=20 Hi S. Moonesamy, I'm not exactly sure what you are suggesting, but that's why Access is here -- to help highlight the importance of this proposal to the folks who are actively involved in the discussion and consideration of proposals for the specification. Waiting and assuming that an encrypted TLS handshake by default will appear in the TLS 1.3 specification seems like a non-ideal approach, given that without discussion, a proposed implementation, and support, it will likely not get there. We recognize honing a proposed implementation is a lot of work and we want to support those who are currently discussing and drafting one. It is worthwhile, and the real-world impact will be tangible. It's difficult for these communities to ensure their needs are taken into account given that they are non-technical, unaware of the IETF, and obviously not part of the process. We want to make sure such users are protected as much as possible by the default behavior of the communications methods they rely on, hence the importance of having the handshake be encrypted by default. Let me know if I missed the thrust of your concern, happy to continue the discussion off-list. Michael > Regards, > S. Moonesamy >=20 > 1. It could be argued that leaking the information should be considered= > as part of the (IETF) security considerations. --=20 Michael Carbone Manager of Tech Policy & Programs Access | https://www.accessnow.org GPG: 0x81B7A13E Fingerprint: 25EC 1D0F 2D44 C4F4 5BEF EF83 C471 AD94 81B7 A13E --9wT5eVSCHBiHjFoR588fn13rOBT6Txr4P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTd76cAAoJEDH9usG3Jz33ZWUP/0WWSu+4rj5g6lGbVmNKgKOO pa+8vOpIEmtX7Ht9HHH85r8MT64C67jVWXYJMOnJF0MiQPg9JTQ5WFZFAV1iAoka aObFJb5dM3nUBmqIJZ/ajnbL0ZHgVWBUq2qhdM03Bh+4pvTUot8AFSjC3T/pHCNn 28LGkqdWVcUpHyVj1YiKfiz+vuEEZ52MEUgIBglx8Qe14mFvp4MH6GLkolHBjl8H 2kV1KpqQxstexEry2optILbfj30yLfFxTx541yPBw0s3cgZLb3Uu2gYx1GCSQE/s 7QEgs0xTQpzgsH8zZMehndJWcc70FGgACG+B5WvmZK2/hwY4spJWfOJKASdCqxcx GaGju/9S3n6pePD423wkgIT2Qz8DkZgl0vWjr+bCNs+UDpOtQme/YiIsPF45lcpq h17KYM6KxI3hIKEPz/79AFSZ9wxELYJ8/cpXHxthUrPnQKZD5U6ZWEpJuoqs/sxL MbpJ8akzsXLEWO9kN1NJr1rwPmHAcOAsUb2a6zb/ReBIw0nRA3rDW6K9qMcbO+xa GRvbbFuJGl4INBSAxe3fEBSxXXMTlMT5zjjqBODEd3VdyaQBQwlw0zYtu2oDUIPO yroDd40O3p0hdQV5m1mwB4mWWv2yAtC/MgN+l9UwQD2idQyG7Z3YFjndbmMuwNW/ PV91+grKwef0kVHkAmdN =ZX/M -----END PGP SIGNATURE----- --9wT5eVSCHBiHjFoR588fn13rOBT6Txr4P-- From nobody Sat May 17 20:39:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000101A0011 for ; Sat, 17 May 2014 20:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYMvofvGNtyV for ; Sat, 17 May 2014 20:39:46 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 35F2B1A000C for ; Sat, 17 May 2014 20:39:46 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id ECB7F2F4059 for ; Sat, 17 May 2014 20:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=ssiLiJ3ycpo7K6ZP3+cxnu+wxIY=; b=NcIIYIs+ADS A356lZNpz4lLR4q87lKB+oMi+oMwRUDqXbb9mQwWBXztiZLm3EyelHjbERkYNURd Gm56A1ndLGEKh+5EkndhIQsBsv8CI2niXhgKPnaOqM+0OTEmS7KO2CwjNGWB7k3F iPqojsgoQLoDRFUOZbLQJ8xFhuQcq5DA= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id A03342F4057 for ; Sat, 17 May 2014 20:39:45 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so6559704wgg.30 for ; Sat, 17 May 2014 20:39:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.34 with SMTP id kr2mr22507412wjb.34.1400384384367; Sat, 17 May 2014 20:39:44 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sat, 17 May 2014 20:39:44 -0700 (PDT) Date: Sat, 17 May 2014 22:39:44 -0500 Message-ID: From: Nico Williams To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e01229990c785a504f9a46587 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_aE7MY-rTud96DdPsSWZ-2x9OKU Subject: [TLS] SNI privacy compromise: only for resumption in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 03:39:47 -0000 --089e01229990c785a504f9a46587 Content-Type: text/plain; charset=UTF-8 How about only providing SNI privacy in resumption handshakes only in 1.3? Clients that really want it would have to do an extra handshake before they could use a session with SNI. To do this right and extensibly to a future with DNSSEC with privacy we'll need an extension that is always present (even in initial, non-abbreviated handshakes, and even when not actually desired) whose payload is intended to identify an encryption key (but without identifying the server's name, such as a hash of the key found with DANE, or a key derived from the session key of the resumption ticket) and an encrypted payload, with plaintext padded to obfuscate name lengths, or maybe a hash of the desired name. The server should send its certificate in an encrypted -also always present- extension in its reply. The key for encrypting the reply should be derived from the new session's session keys. The additional cost of this for resumption should be marginal (only a bit of extra symmetric key crypto). And it gives us a way to also do it right in the future for non-resumption handshakes. Nico -- --089e01229990c785a504f9a46587 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about only providing SNI privacy in resumption handshakes only in 1.3?<= div>
Clients that really want it would have to do an extra ha= ndshake before they could use a session with SNI.

To do= this right and extensibly to a future with DNSSEC with privacy we'll n= eed an extension that is always present (even in initial, non-abbreviated h= andshakes, and even when not actually desired) whose payload is intended to= identify an encryption key (but without identifying the server's name,= =C2=A0such as a hash of the=C2=A0key found with DANE,=C2=A0or a key derived= from the session key of the resumption ticket) and an encrypted payload, w= ith=C2=A0plaintext padded to obfuscate name lengths, or maybe a hash of the= desired name.

The server should send its certificate in an=C2=A0encrypted = -also always present-=C2=A0extension in its reply. =C2=A0The key for encryp= ting the reply should=C2=A0be derived from the new session's session ke= ys.

The additional=C2=A0cost of this for resumption should be margin= al (only a bit of extra symmetric key crypto). =C2=A0And it gives us a way = to also=C2=A0do it right in the future for non-resumption handshakes.
=

Nico
--=C2=A0
--089e01229990c785a504f9a46587-- From nobody Sat May 17 22:04:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED261A02BD for ; Sat, 17 May 2014 22:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzVCM_g2Aok3 for ; Sat, 17 May 2014 22:04:42 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F161A02AE for ; Sat, 17 May 2014 22:04:42 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id q9so3485813ykb.35 for ; Sat, 17 May 2014 22:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m8d1NkX+vRdzhVvPPHk8/fHswB4DTM0uUjC0qOSKCLY=; b=AKtr67wtUbcFSDqvEF1F67mr6tcdAR2iy82JULK3nyyKdlDFiTioZ0pk23MIWKbNXM bVug10OTSAK9I1dKSnziLyl9YDZjtl0nmXoU4QAM+p/HCcsmYVIyg05NwJ7LP+MBNryz ORGZ+8TNs8kPa0tiX7P4/uosTEMjnCYgKh2GqneC1I9NRuh4IXYnJFNBT7kLNcphaG7y 5vlj6y1JJbWF/gaG1Dd/n6WTLWuaYdk6mnFm9QYy9vcEnZruPyEnzEuprzixmSsh4NOe wqG6nYz4bDAc4ofIKzgVIVFN/NryQy9Gnhk1JosuFmc2BQyiT2KYIQ3VmayFwPCdUGOY 14Fg== MIME-Version: 1.0 X-Received: by 10.236.179.69 with SMTP id g45mr40635233yhm.81.1400389481910; Sat, 17 May 2014 22:04:41 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 17 May 2014 22:04:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 May 2014 22:04:41 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zbyzqXonUXkjgyO_Eoxd9x3nvi8 Cc: "tls@ietf.org" Subject: Re: [TLS] SNI privacy compromise: only for resumption in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 05:04:44 -0000 On Sat, May 17, 2014 at 8:39 PM, Nico Williams wrote: > How about only providing SNI privacy in resumption handshakes only in 1.3? > > Clients that really want it would have to do an extra handshake before they > could use a session with SNI. How does this help? I can think of one way: the ticket is marked with the name of the server that sent it somehow. Maybe this addresses the middlebox issue. However, for anti-censorship this is useless as the SNI is sent on the first handshake, and so can be used to censor a connection: you don't ever get to resume. > > To do this right and extensibly to a future with DNSSEC with privacy we'll > need an extension that is always present (even in initial, non-abbreviated > handshakes, and even when not actually desired) whose payload is intended to > identify an encryption key (but without identifying the server's name, such > as a hash of the key found with DANE, or a key derived from the session key > of the resumption ticket) and an encrypted payload, with plaintext padded to > obfuscate name lengths, or maybe a hash of the desired name. What stops the censor from looking up the data that will be sent in the identification tag? Or are you suggesting something along the lines of Option 3, where the key corresponds to IP address/machine? > > The server should send its certificate in an encrypted -also always present- > extension in its reply. The key for encrypting the reply should be derived > from the new session's session keys. Why does a resumed connection require presentation of certificates? A resumed connection has a key that (if TLS had been designed correctly) would only be known by the server and the client. I assume we are fixing this in TLS 1.3. Or were you discussing the general case of encrypted SNI, where we do need to protect the entire handshake because of the places names can appear. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun May 18 01:38:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F761A01BF for ; Sun, 18 May 2014 01:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRbggdCd_zdK for ; Sun, 18 May 2014 01:38:23 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1203A1A0170 for ; Sun, 18 May 2014 01:38:22 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so4304271wes.16 for ; Sun, 18 May 2014 01:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=48qWvFx8t6ltoDTDtlxM1w4z0TqhOMKYkiOArAtbUJo=; b=GfC5ubkhXsYz3qQSS0ohJ/kwGGJSP5Q1Mwcsa7Y5SOD/Bkh8fD8xwTqd5569WZmYRR CAvZzwdfKsA6XKswfXmyMtmJpyho/QXPnRuJC+oUvYKX3RYoYMkSLcXP9sFSaOr/LZqh U9oHWj8aCepAmf2hm9BhkjQmUU0Du8b1U9ioRp2ARbrzfadXkH9M4o6OotxJEKxxMfJb sjgLAWpdtci/27Nx0Wi4GEKtEZawK02eVS56ndi8KpuaA+jujxrPM5V2jpq22nvPAFU3 rX+nOY8Y48V1lSg3bENJJu5k0Y4Up01nhQ00sjMj1zik5ljdvw+1FLIWQVP8guOZNVSU gV6Q== X-Received: by 10.180.109.69 with SMTP id hq5mr6779628wib.30.1400402301471; Sun, 18 May 2014 01:38:21 -0700 (PDT) Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id b16sm9082075wjx.45.2014.05.18.01.38.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 May 2014 01:38:20 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Sun, 18 May 2014 11:38:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <644A952F-5DA9-484D-A84B-2D3D26663C32@gmail.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JyYWEPWV5hQvJ8pcZp7uUnRNNAg Cc: "tls@ietf.org" Subject: Re: [TLS] SNI privacy compromise: only for resumption in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 08:38:24 -0000 On May 18, 2014, at 6:39 AM, Nico Williams = wrote: > How about only providing SNI privacy in resumption handshakes only in = 1.3? >=20 > Clients that really want it would have to do an extra handshake before = they could use a session with SNI. >=20 > To do this right and extensibly to a future with DNSSEC with privacy = we'll need an extension that is always present (even in initial, = non-abbreviated handshakes, and even when not actually desired) whose = payload is intended to identify an encryption key (but without = identifying the server's name, such as a hash of the key found with = DANE, or a key derived from the session key of the resumption ticket) = and an encrypted payload, with plaintext padded to obfuscate name = lengths, or maybe a hash of the desired name. >=20 > The server should send its certificate in an encrypted -also always = present- extension in its reply. The key for encrypting the reply = should be derived from the new session's session keys. Which certificate does the server send? If the server always sends the = same certificate, there=92s no point in SNI privacy.= From nobody Sun May 18 07:50:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5751A0269 for ; Sun, 18 May 2014 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIOUhduIdssq for ; Sun, 18 May 2014 07:49:50 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9291A022A for ; Sun, 18 May 2014 07:49:50 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hr9so8426308vcb.17 for ; Sun, 18 May 2014 07:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BS2UasDrNjY2gGqZBBmzameFccQKjQZxxXytVb/JUEY=; b=eLrVlLmkG7kDRJ23gJ9YqZZhcR9yvL37rpwdNzXSj9lGBL32JLz8CZ1OE+3SgbM8yp Zs3YiKVJ/oWeLJ+A7P7vdwk2vfH7LkFpU4R33FoD5Eh0y/tQJJMrxW341uja1k1sOeHo flwPdi0/S+d0EKnInj8LOBgux+LoVkhIX4kjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BS2UasDrNjY2gGqZBBmzameFccQKjQZxxXytVb/JUEY=; b=cUuHPRjxF+DkPCByqZg0Vm2CV2nMLIiwoDdHJh07+UxmLdb/yrORiOQdhV8d/O0bPR N5Gd8fgsfB5ug9V40pWMIV3/w+ieFhE6LO7TnoJVqV0yEGLqNd69C6VzYmnAeXtAmcun C2zbRIGG0whfENfLwDZBflxmvCv7IJWJfkMI1lRTUuhLDpabeBGR4KquLmVF8Z+ic+RO pzKrkfdeSO7Qtot9duPpZvlH3PtPyPbB7UsLxUa09i4PB+vf+TU8nQMtDaOCMkGZf584 ddqLnoOmdIAZvDVbUHW5m9csZJjmk6ObebplYZVB5wYMET/RY3N0dZ/ml1iSkzJ5kblm iV2w== X-Gm-Message-State: ALoCoQl0DiD894dsMa0YHm8wcWmYn7qIwb9Iqcrb5yr+Ua6xRx7vjwH+CXIFq9mJpo34+lARIsq1 X-Received: by 10.221.42.135 with SMTP id ty7mr9368960vcb.14.1400424589819; Sun, 18 May 2014 07:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.39 with HTTP; Sun, 18 May 2014 07:49:29 -0700 (PDT) In-Reply-To: <644A952F-5DA9-484D-A84B-2D3D26663C32@gmail.com> References: <644A952F-5DA9-484D-A84B-2D3D26663C32@gmail.com> From: Tom Ritter Date: Sun, 18 May 2014 10:49:29 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h5TXeRBqj0weYk74-gifDTdfkv8 Cc: "tls@ietf.org" Subject: Re: [TLS] SNI privacy compromise: only for resumption in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 14:49:51 -0000 Having SNI privacy in resumption or the 0-RTT will probably only make things worse, as it becomes a fingerprinting methodology for the attacker. I force you to connect to subversive.github.io and if you do 0-RTT or resume, I know you've visited there before. Instead what you want is the client to behave the same way as if you had never visited there before. If the client wants to protect SNI it will either look up a key via an out-band-of-band method (to keep 1-RTT, this could be in DNS in a B-Record as suggested by Eric Nygren[0]) or via an in-band mechanism using 2-RTT. On 18 May 2014 01:04, Watson Ladd wrote: > What stops the censor from looking up the data that will be sent in > the identification tag? Or are you suggesting something along the > lines of Option 3, where the key corresponds to IP address/machine? I believe (or at least I'm rewriting it in my mind) that he is. The Key/KeyID is used for multiple sites, so it protects SNI. A site and the middlebox/target of the A/B/CNAME record (which might be the same person) COULD 'collude' to make the Key/KeyID into an SNI equivalent, but I think I'm okay with that because if they're willing to leak the information for deployment reasons, they will probably do so in some way - you can't force them to protect it everywhere, you can only make protecting it the default. Sites that want to protect it will protect it, and the encrypted-SNI and SNI-equivalent-KeyID flows look identical on the wire so the censor actually has to go to the trouble of figuring out which is which. -tom [0] http://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2014-tls-1-0.pdf From nobody Sun May 18 08:36:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75191A02D6 for ; Sun, 18 May 2014 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD8nOsXPMfmw for ; Sun, 18 May 2014 08:36:23 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 26AF31A0107 for ; Sun, 18 May 2014 08:36:23 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 0AAC09A405D; Sun, 18 May 2014 11:36:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Wh13lndJZKVT; Sun, 18 May 2014 11:35:51 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BB8969A405C; Sun, 18 May 2014 11:35:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Sun, 18 May 2014 11:35:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25179EF6-2691-4970-A2A0-B5FD578FF734@vigilsec.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oHLIczVTaZFhw1KzKdhCXm7iWk8 Cc: "tls@ietf.org" Subject: Re: [TLS] SNI privacy compromise: only for resumption in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 15:36:25 -0000 Nico: I do not understand your suggestion. When I guess at your meaning, TLS = 1.3 seems more frail. So, I will stop guess and ask you to explain. Russ On May 17, 2014, at 11:39 PM, Nico Williams wrote: > How about only providing SNI privacy in resumption handshakes only in = 1.3? >=20 > Clients that really want it would have to do an extra handshake before = they could use a session with SNI. >=20 > To do this right and extensibly to a future with DNSSEC with privacy = we'll need an extension that is always present (even in initial, = non-abbreviated handshakes, and even when not actually desired) whose = payload is intended to identify an encryption key (but without = identifying the server's name, such as a hash of the key found with = DANE, or a key derived from the session key of the resumption ticket) = and an encrypted payload, with plaintext padded to obfuscate name = lengths, or maybe a hash of the desired name. >=20 > The server should send its certificate in an encrypted -also always = present- extension in its reply. The key for encrypting the reply = should be derived from the new session's session keys. >=20 > The additional cost of this for resumption should be marginal (only a = bit of extra symmetric key crypto). And it gives us a way to also do it = right in the future for non-resumption handshakes. >=20 > Nico > --=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun May 18 11:14:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6B1A02D3 for ; Sun, 18 May 2014 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.259 X-Spam-Level: X-Spam-Status: No, score=0.259 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ--NOaoFGQL for ; Sun, 18 May 2014 11:14:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D11A027D for ; Sun, 18 May 2014 11:14:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.60]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4IIE6e0006916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 May 2014 11:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400436867; bh=FYkAN6YSRvSLXKBox2pVDq4MIA5PobXMTtNOTncNffM=; h=Date:To:From:Subject:In-Reply-To:References; b=xnwQBGIeA5bRfzaaFcPQWXy/yes/8Y+NHL3brF3f9hwrqqtVuh9XQ0/E34XBLabib UlBwSuB3kESLxwHoZDrRPuehdMl2dY+n11Y28g5ZDIDTDPz8rNzN8wvZSA2MOlx6Ks IL3do0lSQLx3TFepFO7+faea20r17Hjhkq7OlUYQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1400436867; i=@elandsys.com; bh=FYkAN6YSRvSLXKBox2pVDq4MIA5PobXMTtNOTncNffM=; h=Date:To:From:Subject:In-Reply-To:References; b=v0mDYaO46W71/PHq4oxxGyJRaZf41nDdE6XJHppuPRqXcikEeK7POb4TzTUEhWBmn /QEAg2rsAIGnD5YBaP7lVz/UHMiKTY4ntQPg58hTsnr7aCNIdoPnK48W+VQzXEdapP cnJExyRikEpAiFRS9cDSqsZUecrbLZ8sIftvuN1Q= Message-Id: <6.2.5.6.2.20140518090340.0c1a97d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 18 May 2014 10:12:57 -0700 To: Michael Carbone , tls@ietf.org From: S Moonesamy In-Reply-To: <5377BE89.6000807@accessnow.org> References: <5373C4F3.3010602@blah.is> <6.2.5.6.2.20140517075513.0bc6bfa8@resistor.net> <5377BE89.6000807@accessnow.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EHCVSKFCLLpVJRAPp1iOpP_MyDk Subject: Re: [TLS] In support of encrypting SNI (off-topic) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 18:14:48 -0000 Hi Michael, At 12:54 17-05-2014, Michael Carbone wrote: >I'm not exactly sure what you are suggesting, but that's why Access is >here -- to help highlight the importance of this proposal to the folks >who are actively involved in the discussion and consideration of >proposals for the specification. > >Waiting and assuming that an encrypted TLS handshake by default will >appear in the TLS 1.3 specification seems like a non-ideal approach, >given that without discussion, a proposed implementation, and support, >it will likely not get there. We recognize honing a proposed >implementation is a lot of work and we want to support those who are >currently discussing and drafting one. It is worthwhile, and the >real-world impact will be tangible. I agree that waiting and assuming that the outcome of a specification would be favorable is a non-ideal approach. >It's difficult for these communities to ensure their needs are taken >into account given that they are non-technical, unaware of the IETF, and >obviously not part of the process. We want to make sure such users are Yes. Although it might not be the intent the message came out as designing a TLS specification to bypass censorship for political reasons. There were two organizations [1] which posted comments along those lines. I suggested framing the comments as technical input and avoid the political advocacy angle. Note that I am okay with encrypting the SNI as the average user would expect that the information being sent can only read by the endpoint on the other side. Regards, S. Moonesamy 1. I am aware of how affiliation works in the IETF. I used the word in my explanation for clarity. From nobody Sun May 18 21:05:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAB01A005E; Thu, 8 May 2014 09:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6awVsC_FYffF; Thu, 8 May 2014 09:27:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id BF88B1A005A; Thu, 8 May 2014 09:27:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 81FEB180014; Thu, 8 May 2014 09:26:35 -0700 (PDT) To: mrex@sap.com, tdierks@certicom.com, pck@netcom.com, relyea@netscape.com, jar@netscape.com, msabin@netcom.com, dansimon@microsoft.com, tomw@netscape.com, hugo@watson.ibm.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140508162635.81FEB180014@rfc-editor.org> Date: Thu, 8 May 2014 09:26:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rsTXm36XmlcekTFPbq5lLk-QvRA X-Mailman-Approved-At: Sun, 18 May 2014 21:05:55 -0700 Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Rejected] RFC2246 (3481) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:27:19 -0000 The following errata report has been rejected for RFC2246, "The TLS Protocol Version 1.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2246&eid=3481 -------------------------------------- Status: Rejected Type: Technical Reported by: Martin Rex Date Reported: 2013-02-08 Rejected by: Stephen Farrell (IESG) Section: 8.1.2 Original Text ------------- 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Corrected Text -------------- 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret. Notes ----- Adopting the clarification from rfc4346 Section 8.1.2. Not stripping the leading zero bits of Z will cause interop problems (handshake failures) with the installed base. Rfc2246 is still the authoritative spec for TLSv1.0. One can not implement TLSv1.0 from rfc4346. --VERIFIER NOTES-- We don't post errata for things fixed when an RFC is obsoleted. -------------------------------------- RFC2246 (no draft string recorded) -------------------------------------- Title : The TLS Protocol Version 1.0 Publication Date : January 1999 Author(s) : T. Dierks, C. Allen Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sun May 18 21:05:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82401A077D; Mon, 12 May 2014 14:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIdkO73J0eVz; Mon, 12 May 2014 14:07:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5171A0767; Mon, 12 May 2014 14:07:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: sfriedl@cisco.com, andreipo@microsoft.com, agl@google.com, emile.stephan@orange.com X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140512210747.10675.45300.idtracker@ietfa.amsl.com> Date: Mon, 12 May 2014 14:07:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/63CH5YqZGrx6bEJ5q8Kp1BWtwdU X-Mailman-Approved-At: Sun, 18 May 2014 21:05:54 -0700 Cc: Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] IPR Disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 21:07:49 -0000 Dear Stephan Friedl, Andrey Popov, Adam Langley, Stephan Emile: An IPR disclosure that pertains to your Internet-Draft entitled "Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension" (draft- ietf-tls-applayerprotoneg) was submitted to the IETF Secretariat on 2014-05-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2357/). The title of the IPR disclosure is "INEOVATION's Statement about IPR related to draft-ietf-tls- applayerprotoneg-05.""); The IETF Secretariat From nobody Sun May 18 21:06:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7981A01FE; Tue, 13 May 2014 14:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej0ZcsGKJos4; Tue, 13 May 2014 14:46:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1011D1A01A5; Tue, 13 May 2014 14:46:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: sfriedl@cisco.com, andreipo@microsoft.com, agl@google.com, emile.stephan@orange.com X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513214608.19242.55476.idtracker@ietfa.amsl.com> Date: Tue, 13 May 2014 14:46:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-cPfD2pc6ccj48VAcOeHoHU47q8 X-Mailman-Approved-At: Sun, 18 May 2014 21:05:55 -0700 Cc: Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, ipr-announce@ietf.org Subject: [TLS] IPR Disclosure: INEOVATION's Statement about IPR related to draft-ietf-tls-applayerprotoneg-05 (2) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 21:46:09 -0000 Dear Stephan Friedl, Andrey Popov, Adam Langley, Stephan Emile: An IPR disclosure that pertains to your Internet-Draft entitled "Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension" (draft- ietf-tls-applayerprotoneg) was submitted to the IETF Secretariat on 2014-05-13 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2359/). The title of the IPR disclosure is "INEOVATION's Statement about IPR related to draft-ietf-tls- applayerprotoneg-05 (2).""); The IETF Secretariat From nobody Mon May 19 11:58:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA411A03C8 for ; Mon, 19 May 2014 11:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnqza8jg4W1Q for ; Mon, 19 May 2014 11:58:15 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FFF1A02D1 for ; Mon, 19 May 2014 11:57:48 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fa1so6177258pad.39 for ; Mon, 19 May 2014 11:57:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=abpnzoQiOAJyTjZ5SJLjM+fRW6JHfAH+o3vgZ/NWiVc=; b=FZoY12JhgI83A4kGQUAAgRpHwl2QSoDwUKv+38JRQBh9xlVg3tfdkDMd68Sq2HVM3G oUyMnY6hAwXtj8pNV419z6L4nRggjxxFzD2bLSyI/suJkQMfUnybK6fA5i943/Rx23B4 z2rpToAXD+JR6B3qzNuvR65dJBKSznVZUKDiufBP6vMAMStC2BobgxmlB5gCnz25X7z3 XtM7R/RqLeqQlorkH7CP/km3dpoKmfvO4CCgrogFjv1qaJ7y0mmENBRWI3ZzyLR266ir buyGB0LBBN2v5Wl58EcSiFWH6nU42I8HyV9nHX6uKZpTk7lbVNMLhTywU/s+DxCDE0ZV xMoA== X-Gm-Message-State: ALoCoQl8kARa3AYnUZ5Zk7UvqeumMCml+4eS6IMw5nruc6S6tP88sKZvil4KQTBYdzR/hDGqKXGE X-Received: by 10.68.184.66 with SMTP id es2mr45053947pbc.19.1400525867838; Mon, 19 May 2014 11:57:47 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id ao4sm31120606pbc.51.2014.05.19.11.57.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 11:57:46 -0700 (PDT) Message-ID: <537A5429.4030002@amacapital.net> Date: Mon, 19 May 2014 11:57:45 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-2Na4bCAqbh4M_heV6QRmU8h8y4 Subject: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 18:58:21 -0000 This is inspired ekr mentioning removing some redundant fields and by a discussion at the interim meeting about some TLS padding tricks that won't work unless the record type is encrypted. Regardless of the actual motivation, it should be both a cleanup and an efficiency improvement. Currently, a record is: struct { ContentType type; ProtocolVersion version; uint16 length; select (SecurityParameters.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; case aead: GenericAEADCipher; } fragment; } TLSCiphertext; GenericAEADCipher encodes a TLSPlaintext, which is: struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; There is a lot of redundancy here. The type, version, and length appear twice. Of those, the version appears to be almost completely pointless, and the type and length don't need to appear twice. If I'm counting right, fixing this will save six bytes in every record. Fixing this may also reduce the chance that implementations screw up checks related to record lengths: there's now only one length field. This could be as simple as: struct { uint16 length; GenericAEADCipher ciphered_plaintext; } TLSCiphertext; struct { ContentType type; opaque plaintext_fragment[plaintext length - 2]; } TLSPlaintext; This may require some fiddling with the AAD part of the GenericAEADCipher construction. Doing this in a way that's backwards compatible with TLS 1.2 and below might require some tweaks to the handshake protocol -- the redundant fields will probably have to be-added. Thoughts? Should I try to write up a pull request? --Andy From nobody Mon May 19 12:04:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF101A03A2 for ; Mon, 19 May 2014 12:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVyuj8Myst88 for ; Mon, 19 May 2014 12:04:26 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4C91A0354 for ; Mon, 19 May 2014 12:04:26 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id oz11so6876153veb.2 for ; Mon, 19 May 2014 12:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uwjL+Fl7aisR4jIOeqehdZIhWCdpmmBFiczu4Ux2ly4=; b=RgGe/JYUr7zV8jfWmu83/s11dfcS0dU2eOgqZm5eA+JhMfZ75kWTHQL+p+wj7iyiN1 qULQyB7qTZmvPY5EolG6So8IsPrwnlSc8A5iT7k1PyjqWMnxxI1cMlGcNTKlTGwxx29S C3eGWiVPqma4icFivXbkS9ZNNr7hYVQL5ruA5JNg6CgqHgp1lrO3ukofFAtDr3vLNvqd w10JXWkKLylkHVC2rPR2uV4h4dnMoNDd0Hm+TC5t9Cls9263dLtbLWOw1M3l+Zia+znh gZPtpcwvm/zfEuDh90EIW6heb3F/xr5SjiKcWcf8z9tSlm0CafuuxoUF3ISh6IkyAWSz sVNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uwjL+Fl7aisR4jIOeqehdZIhWCdpmmBFiczu4Ux2ly4=; b=VZUBFO17lCDBO6DcKcLD4EhZheqjEpfPmS44CDgw6Eg16HHVBFEmcjLbK2ow6dEEFp XuzFrJBfK4dDk1skoWkVOOmNMAtrnCYLRhbzNdbe072w+IZWXAZt15wvvWlfJdOspkFe Sp/Jx96S7Wu2OBLhWYaetoG5d5PecdKHAgySsE+rP7A59pS7nYofTqsr1kukGHI9Mzlm 5HWZkeABdN6ELY+IieQnvEUPC/QJCv5WZiA5LQAWAFEN1EM/KBjYKkBscbc8WfXdgjwc eLx3/JXVmJUKEOQuumcye7L/KO3oGzXqTWxpUGcHnLznvPJPkUzQqe12A0hpJ6CPnuDu bi+Q== X-Gm-Message-State: ALoCoQkPrfrdkXLmPXHGkU878xAtDuC6gDFkQFdyXbsiJhU8aBHoWmKWQkuB3mtUODlIhozKrV6B X-Received: by 10.52.13.98 with SMTP id g2mr1965953vdc.46.1400526265472; Mon, 19 May 2014 12:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Mon, 19 May 2014 12:04:05 -0700 (PDT) In-Reply-To: <537A5429.4030002@amacapital.net> References: <537A5429.4030002@amacapital.net> From: Adam Langley Date: Mon, 19 May 2014 12:04:05 -0700 Message-ID: To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oVliYX15M3DYk3PQDf2GxAB0xNs Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:04:28 -0000 On Mon, May 19, 2014 at 11:57 AM, Andy Lutomirski wrote: > There is a lot of redundancy here. The type, version, and length appear > twice. Of those, the version appears to be almost completely pointless, > and the type and length don't need to appear twice. If I'm counting > right, fixing this will save six bytes in every record. Putting the version in every record is a waste, but TLSPlaintext and TLSCiphertext don't work in the way that you think: the type, version and length aren't repeated on the wire. TLSPlaintext is more of a conceptual structure. A TLS record, on the wire, contains only the 5 byte header of the TLSCiphertext. Cheers AGL From nobody Mon May 19 12:25:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16C01A03BD for ; Mon, 19 May 2014 12:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_TUXsMWCbZ6 for ; Mon, 19 May 2014 12:25:47 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3701A03C3 for ; Mon, 19 May 2014 12:25:47 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so6890747veb.24 for ; Mon, 19 May 2014 12:25:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ChiWf2BNK9s37M1AT65cAGDM4C+QkcjEpOCBdvCLcEw=; b=Sext0/ITlk38OI5wBps8KLIOcHtcV9NzuEUbfBgLDiDLl3vgrM1kP/87oQR3oYhsq1 nkXFMOjl/p1mGM9o9PZQ2QztbarHGNDFuTF3LHUwJqf+xlCiP1sMubL0Pxv7sIE+MqSu Fte2Il7IRBKT6V7EiT+sz7mHVk8vv73gC9vak4Iddmmn9qzp92mQWBVeeS9zM/VYYfrK DVRntj//iD9c2kC9bJj/EqDfJl6FYKXVXHzAWZX4Lsi8JJhqs0+anvrILs7pnuEMn/AM lzm0dXdUz8Q3iaGpv3mXq3YOwYUf+dX8jeD+f99dZqzosIlgD4tdz8LTmyT4JtsLMWdV Za8g== X-Gm-Message-State: ALoCoQl0KwwmkepTyhwesWV5mrDn/qvupGBYExefPK7XEkCwbN/7JozEIoiUbeE/CAmlV3a2uCUC X-Received: by 10.220.59.65 with SMTP id k1mr16296707vch.22.1400527546564; Mon, 19 May 2014 12:25:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.246.39 with HTTP; Mon, 19 May 2014 12:25:26 -0700 (PDT) In-Reply-To: References: <537A5429.4030002@amacapital.net> From: Andy Lutomirski Date: Mon, 19 May 2014 12:25:26 -0700 Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NusTGq9hZPTkD948BNof73wa650 Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:25:50 -0000 On Mon, May 19, 2014 at 12:04 PM, Adam Langley wrote: > On Mon, May 19, 2014 at 11:57 AM, Andy Lutomirski wrote: >> There is a lot of redundancy here. The type, version, and length appear >> twice. Of those, the version appears to be almost completely pointless, >> and the type and length don't need to appear twice. If I'm counting >> right, fixing this will save six bytes in every record. > > Putting the version in every record is a waste, but TLSPlaintext and > TLSCiphertext don't work in the way that you think: the type, version > and length aren't repeated on the wire. TLSPlaintext is more of a > conceptual structure. A TLS record, on the wire, contains only the 5 > byte header of the TLSCiphertext. Egads! So that's what "opaque content[TLSPlaintext.legnth]" means. In any event, the version should still be removable (at least after the first ChangeCipherSpec), and it would still be nice to encrypt the record type. Of course, doing that probably means that the record type should be removed from the additional_data bit. --Andy From nobody Mon May 19 12:26:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B7E1A03C2 for ; Mon, 19 May 2014 12:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1bipe0-VNbn for ; Mon, 19 May 2014 12:26:14 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E801A03C3 for ; Mon, 19 May 2014 12:26:13 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so4749716wiw.10 for ; Mon, 19 May 2014 12:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=go9T0tAkkzD/dTeeRZFKqZ9hIBB+cJe/yehHSJMzIUA=; b=c2XkU2ZbgyayB69wW5Cqw5sAhdDuPrPpuwuOVLVSzDwZDHj/WY27QvG3huuIS9lwdf XYL4KLmlw9VSy6QQiWPPLJNulaXB8qWZKT2vuBh5s81tWhic8ZdOFAg761dZKBVFb7y5 1Jy+L4zQ39lM/FstE+8LPK4/OIScXbwdgM0yFn3HFUXMZZh1BcDRUirgq0y8agZJ+dnG Bz7slidj3l+YCy9I39E5sw95RiptkdtzIDUOCTP4ukgWahCC91sOE/wiP5xXUDLO/fai UZ9qFIHi8DuRCBO3gKnOFQV7zZy65Fjh/frSg6GzfBWVHNG+cRgVZXbYW/IBVhV+dwFu re8Q== MIME-Version: 1.0 X-Received: by 10.194.9.8 with SMTP id v8mr19894871wja.53.1400527572447; Mon, 19 May 2014 12:26:12 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Mon, 19 May 2014 12:26:12 -0700 (PDT) In-Reply-To: References: <537A5429.4030002@amacapital.net> Date: Mon, 19 May 2014 12:26:12 -0700 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y03Os90wvXmPyYLxTJcvQswYdvU Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:26:17 -0000 On 19 May 2014 12:04, Adam Langley wrote: > On Mon, May 19, 2014 at 11:57 AM, Andy Lutomirski wrote: >> There is a lot of redundancy here. The type, version, and length appear >> twice. Of those, the version appears to be almost completely pointless, >> and the type and length don't need to appear twice. If I'm counting >> right, fixing this will save six bytes in every record. > > Putting the version in every record is a waste, but TLSPlaintext and > TLSCiphertext don't work in the way that you think: the type, version > and length aren't repeated on the wire. TLSPlaintext is more of a > conceptual structure. A TLS record, on the wire, contains only the 5 > byte header of the TLSCiphertext. Bad presentation in RFC 5246 notwithstanding, I think that Andy's proposal has merit. This drops the version, encrypts the type. I was going to go one further and suggest collapsing the handshake messages down into the same structure, using the ContentType to indicate not just that the message is a handshake message, but to also include what type. That would have the consequence of reducing the size of a handshake message down to 64K (from 16M), but I think that's probably manageable. The big challenge that this sort of proposal introduces is that it makes it hard to do DTLS-SRTP demux. See http://tools.ietf.org/html/rfc5764#section-5.1.2 One potential way to address that is to reduce the maximum record size further. and use the bits reclaimed to distinguish DTLS records. 2^14 might be workable. From nobody Mon May 19 12:33:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBFB1A0192 for ; Mon, 19 May 2014 12:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FXsJGfI93Nf for ; Mon, 19 May 2014 12:33:31 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D8B1A0156 for ; Mon, 19 May 2014 12:33:31 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so10072339vcb.38 for ; Mon, 19 May 2014 12:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=L6PmdKAVKz8+u8Ps5wm/O8/VtplROwt4FfO+kRcBpOs=; b=Jcw7gwlh4Wxsek668AfHTgqfj+VmkBcOLQTGAiE+tGvWFzzAOkyS3rMcJmGamCFENC iVfGuZTOwvgxcteTZva6yrcr+SOxYbZhLXkAj57pQNEOUBDA31+ezMHOEMoCznXpKqq5 qgP9zDTt1mXERM0zOuilY3RMuHkegcl6EEd+ztooJIddDCPEHdBxooX1+u2WCQi6laaG +fRCn8tUN6LOqV9u7tf/MzbJw/yMhZRl+EdIa4pi7vH0UbdrSqeuLvoltRlb+n6G033I 0HwZFbSWtGM+ScoPnFwgvsPJwas6WKdVSyk8he/2QMwxT+P53zC3N2ZPgzrzL3zEs162 4vgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=L6PmdKAVKz8+u8Ps5wm/O8/VtplROwt4FfO+kRcBpOs=; b=cJ4WICNq1B0U9TbI3DELcbJ3BcMpedkkV2ijctomQzOU/T/4tg7pb/VKuBL0fFb60U seTxbiVmuZk08NBuTJ5aEVnddAt+Wj0hXAAYYkSj7ToITVHtIlW9BIbUT8+7BRc2V8Xj 6EPAbeXAIZfZaKfWdU1Y323QfLb9zBupCVOU+Ylu8OzbW0hsC1PnzLSFnSzmiDo86K35 HuenCDGO43DFcktXVgYJKtWPW0PpGMRve6Z5CnOJDO2VQl3ArxPjOJnHjlKxyRuzzF69 jL4H0ISgN5kR5L/5M6Cb3jK6wG43YMFjLAvoodReerZn1PSLad+ujczq3Bm5X5lzwLPN 6JSg== X-Gm-Message-State: ALoCoQkRomiq0xcXt7n+H6+UqWP8uG11LIoQvp64g0pW6u/TsR7rb2HOKMpXgjyFMggJfSm/pP+k X-Received: by 10.52.37.48 with SMTP id v16mr13680298vdj.4.1400528010819; Mon, 19 May 2014 12:33:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Mon, 19 May 2014 12:33:10 -0700 (PDT) In-Reply-To: References: <537A5429.4030002@amacapital.net> From: Adam Langley Date: Mon, 19 May 2014 12:33:10 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u_wZbTggn1gAvrcDp_MAaMn9I68 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:33:34 -0000 On Mon, May 19, 2014 at 12:26 PM, Martin Thomson wrote: > That would have the consequence of reducing the size of a handshake > message down to 64K (from 16M), but I think that's probably > manageable. The situation where a >64KB handshake message often arises is in the CertificateRequest message from a server to a client. Some servers have a full root-set installed (say, Mozilla's set) and listing the names of all the roots takes a lot of space. In that situation, it's almost the case that it would be better if the server didn't send any CAs at all in the cert request. Although I guess it does allow clients to exclude any credentials issued by private authorities. Also, in the future, a post-quantum certificate chain, or PQ key-agreement may exceed 64KB. The short keys and signatures that we currently enjoy might be gone in a few decades. Cheers AGL From nobody Mon May 19 13:59:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E421A03FC for ; Mon, 19 May 2014 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mdb7VvMXscsn for ; Mon, 19 May 2014 13:58:56 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C8A1A02BC for ; Mon, 19 May 2014 13:58:56 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id D2AC633D0DF; Mon, 19 May 2014 20:58:55 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Adam Langley References: <537A5429.4030002@amacapital.net> From: Geoffrey Keating Date: 19 May 2014 13:58:55 -0700 In-Reply-To: Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XbymUc3iSdD6gYb3yHlniW713lE Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 20:58:58 -0000 Adam Langley writes: > On Mon, May 19, 2014 at 12:26 PM, Martin Thomson > wrote: > The situation where a >64KB handshake message often arises is in the > CertificateRequest message from a server to a client. Some servers > have a full root-set installed (say, Mozilla's set) and listing the > names of all the roots takes a lot of space. There are also certificates today that exceed 64K, due to long lists of valid domain names; that would be the ServerCertificate message. From nobody Mon May 19 14:17:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB501A0176 for ; Mon, 19 May 2014 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgavHhe2U_5E for ; Mon, 19 May 2014 14:17:25 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00D61A03C9 for ; Mon, 19 May 2014 14:17:24 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so4891372wiv.15 for ; Mon, 19 May 2014 14:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AH75n+uMvhosS3GXP85ucJlCI2yq7zunr13Q6sidxG0=; b=QKBzHc4uTKv9MmpMyKfYQnA+346VVY4tYTYYMYDA5ZQZPbT878i7shSBqSw1jwg5Ks K1J3h8/MBwM6Bg0Nmon9+hPXoOsqwWitiltmZ3+3X3ACWFcTm9tZDwWIQlbYDpjtiSAw fuz7KhWyEcMQ3aNFSUnszbBtzNhfy3zeUFjaOS6Uc3HU2942M+ecP0F8Zrc08MdHSB7c dmw4qABg8dJg9k0Bt0LWpVAzE/fFpd1Y6Nm/84oRoi0UhHM66bsWR/M5QY55HdH9AsbF Pf8jZDAVgRj2EpCUqUmgYjqJS/QfwipJZPqQZvxPf7m/hw/KxkKkqGc0Qn3xx3B4r4Zy jIag== MIME-Version: 1.0 X-Received: by 10.194.219.164 with SMTP id pp4mr32265866wjc.19.1400534243259; Mon, 19 May 2014 14:17:23 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Mon, 19 May 2014 14:17:23 -0700 (PDT) In-Reply-To: References: <537A5429.4030002@amacapital.net> Date: Mon, 19 May 2014 14:17:23 -0700 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bcv4a6auGV9B1Xflmwwu4TUZRVc Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:17:29 -0000 On 19 May 2014 12:33, Adam Langley wrote: > In that situation, it's almost the case that it would be better if the > server didn't send any CAs at all in the cert request. Although I > guess it does allow clients to exclude any credentials issued by > private authorities. The set of distinguished names isn't particularly useful. I don't find that particularly compelling. > Also, in the future, a post-quantum certificate chain, or PQ > key-agreement may exceed 64KB. The short keys and signatures that we > currently enjoy might be gone in a few decades. Yes, I heard several people complaining about the size of keys in a post quantum computing world. From nobody Mon May 19 14:21:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E01A0404 for ; Mon, 19 May 2014 14:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H1OFZfyctbQ for ; Mon, 19 May 2014 14:21:08 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646D31A03FB for ; Mon, 19 May 2014 14:21:08 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so6199757wes.12 for ; Mon, 19 May 2014 14:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iZ6Rf2n4X+Gl+l/TLaZE6ZbFE8qVsC4HzZ91NuXZN7o=; b=OzYHs0N4fkLk2hE+huAFOqTHWZ67rxWMVijwTxt99QYgXj/2PUhp8wY9f4ZPB3q1nz yjF7K47u4g4m8JO3HtoUv/Zv6iQfkiUZIXj1fMuQhW3tYC76BemjHDabKsHsr54ekqNQ 25xFXC0QFmISa8O+0r5h+S2Qpxgd7p3Ged64iIYZWlB3gwid53r5VKQOo6k6mhR988pe vvLAwLHy8rHrVi1WUTlK+LxZwBX/kG6U2c0c1gktJRwHcH43j3Lfghr3N9t74hwVOvgm KL3ISXaamJznkGIlKc2LVbgObzwBQj97BGnvJhoSJsfNUCO2PTpZu2dkVkcPYf2tEoPE SIUg== MIME-Version: 1.0 X-Received: by 10.180.93.101 with SMTP id ct5mr713357wib.23.1400534466988; Mon, 19 May 2014 14:21:06 -0700 (PDT) Received: by 10.194.235.163 with HTTP; Mon, 19 May 2014 14:21:06 -0700 (PDT) In-Reply-To: References: <537A5429.4030002@amacapital.net> Date: Mon, 19 May 2014 14:21:06 -0700 Message-ID: From: Martin Thomson To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NOhrhPV4UK1tN69HFo6-1l1XwgY Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:21:09 -0000 On 19 May 2014 13:58, Geoffrey Keating wrote: > There are also certificates today that exceed 64K, due to long lists > of valid domain names; that would be the ServerCertificate message. That worries me more that the CertificateRequest. From nobody Mon May 19 14:21:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7C11A0415 for ; Mon, 19 May 2014 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeOjEvKuKFRh for ; Mon, 19 May 2014 14:21:13 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id EFB151A0413 for ; Mon, 19 May 2014 14:21:12 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 588EF1655AF; Mon, 19 May 2014 21:21:12 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 4DD161655AD; Mon, 19 May 2014 21:21:12 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 35E5C1E070; Mon, 19 May 2014 21:21:12 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 19 May 2014 17:21:11 -0400 From: "Salz, Rich" To: Martin Thomson , Adam Langley Date: Mon, 19 May 2014 17:21:10 -0400 Thread-Topic: [TLS] Simplifying the record protocol Thread-Index: Ac9zp8UeClmb3iyCTpK7r2+84EclogAAGyNw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> References: <537A5429.4030002@amacapital.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pXVwUHJjtaqObDpHqE5LT_P0RTk Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:21:16 -0000 > Yes, I heard several people complaining about the size of keys in a post = quantum computing world. Handling post-quantum is a design requirement of TLS 1.3? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon May 19 14:24:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E031A019E for ; Mon, 19 May 2014 14:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqv4QivIQ2dt for ; Mon, 19 May 2014 14:23:59 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0830B1A018D for ; Mon, 19 May 2014 14:23:58 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so6175331wes.30 for ; Mon, 19 May 2014 14:23:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ykRrgmBgUbE6O+XF4D6xjScUdqxou0A5TtaxwMgLmpY=; b=iYBzyw/a46VVoVM6n44qvGG9Meiigszw/4D6gY9DhCI1+EVsEVEwxzusmLQho9BhJL KAWx1ruFp+7rAc+4K/p7PnCPXov6eHI7puhpP49tBql91VgrAqnkjckEuvVvOUzllYJP Bi3FbfZpcb2u7OS8qYERrA8X3ro89kMgw9WrBZIog/jPhqvkllgdM0mVDk/u1SkVvYJ9 c7Yh7WJuzDLn8p20iqvo0Kp/5rFsWxahdPUI/jARoZ2MQL/9RKmaDsCm5/TSEqyWop8s m4Sp8m9kINs0yEaVIJei32OQC29pEb8DXOP0pwMQ6Gcd/tuPorbqmzhC+awAdlgYrieL UdIQ== X-Gm-Message-State: ALoCoQmfpeGauY9rt4vkePdm7XfVp6JK2OH29uioB2XtyHnO/kN8Lv3EsVeiLMsm9Vx43OrNLC0u X-Received: by 10.194.187.107 with SMTP id fr11mr5278922wjc.70.1400534637533; Mon, 19 May 2014 14:23:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 19 May 2014 14:23:17 -0700 (PDT) X-Originating-IP: [216.239.55.62] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> References: <537A5429.4030002@amacapital.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Mon, 19 May 2014 14:23:17 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bb03f6092ed2804f9c76116 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ggDMq1rjiKNoEYAssPvjJNt8CP0 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:24:03 -0000 --047d7bb03f6092ed2804f9c76116 Content-Type: text/plain; charset=UTF-8 On Mon, May 19, 2014 at 2:21 PM, Salz, Rich wrote: > > Yes, I heard several people complaining about the size of keys in a post > quantum computing world. > > Handling post-quantum is a design requirement of TLS 1.3? > Not to my knowledge. -Ekr > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rsalz@jabber.me; Twitter: RichSalz > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bb03f6092ed2804f9c76116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 19, 2014 at 2:21 PM, Salz, Rich <<= a href=3D"mailto:rsalz@akamai.com" target=3D"_blank">rsalz@akamai.com&g= t; wrote:
> Yes, I heard several pe= ople complaining about the size of keys in a post quantum computing world.<= br>
Handling post-quantum is a design requirement of TLS 1.3?

Not to my knowledge.

-Ekr=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSa= lz


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7bb03f6092ed2804f9c76116-- From nobody Tue May 20 04:49:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FBB1A068C for ; Tue, 20 May 2014 04:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWw4a-5i1Bb5 for ; Tue, 20 May 2014 04:49:47 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6DD1A0396 for ; Tue, 20 May 2014 04:49:47 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4KBnhC7005707; Tue, 20 May 2014 07:49:43 -0400 Date: Tue, 20 May 2014 07:49:43 -0400 (EDT) From: Hubert Kario To: Rich Salz Message-ID: <1362600428.9953784.1400586583268.JavaMail.zimbra@redhat.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> References: <537A5429.4030002@amacapital.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922) Thread-Topic: [TLS] Simplifying the record protocol Thread-Index: Ac9zp8UeClmb3iyCTpK7r2+84EclogAAGyNwgYbQNA0= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KjGy7D864763DUSf0KH6sDMm3vQ Cc: tls@ietf.org, Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 11:49:48 -0000 ----- Original Message ----- > From: "Rich Salz" > To: "Martin Thomson" , "Adam Langley" > Cc: tls@ietf.org, "Andy Lutomirski" > Sent: Monday, May 19, 2014 11:21:10 PM > Subject: Re: [TLS] Simplifying the record protocol > > > Yes, I heard several people complaining about the size of keys in a post > > quantum computing world. > > Handling post-quantum is a design requirement of TLS 1.3? Don't think so, but if not only all the algorithms but all the protocols will have to be scrapped too, it won't make our future lives any easier. This would also make it a rather surprising regression compared to TLS 1.2 -- Regards, Hubert Kario From nobody Tue May 20 06:25:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4B01A06EC for ; Tue, 20 May 2014 06:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssbvMNPxpjeP for ; Tue, 20 May 2014 06:25:46 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33101A035B for ; Tue, 20 May 2014 06:25:45 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so671050qgf.17 for ; Tue, 20 May 2014 06:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SZfBAFcyA8cOl9VnX8ZEGsiASn5q8pSRoIwREWpYMYc=; b=c8PTUD0A2wf+HrG7DnEim/7ZY+r+Hu5fpfKlv6PAUy+6YEYI47h/fCHqzrl24KGYNH yaA48AKqK1qq3bRzANtORo3SFKu58j5BAbo5DHBtYjxTVfp7iaDH5xC/WntleichBqBh 49RBPNSKMC013vfrGET2ozAymAkTOqcN+ZeqUHpFz/RCHTXWAXz2Lxrjn+JLsuXO3507 M0OATSlhbg41zzsHEGeGf/8wRorkIAeKsk/Dez761qtMbXNxsk3CGgPpLix/DO/uuedo /fsGA1CtZmIxOceeWR0DJASU5pI/RUC6HKQulP3JGJ0df/ec2gAAx+eFunJXUfwmibdI eP4w== MIME-Version: 1.0 X-Received: by 10.140.21.101 with SMTP id 92mr57071870qgk.57.1400592344917; Tue, 20 May 2014 06:25:44 -0700 (PDT) Received: by 10.140.19.229 with HTTP; Tue, 20 May 2014 06:25:44 -0700 (PDT) In-Reply-To: <1362600428.9953784.1400586583268.JavaMail.zimbra@redhat.com> References: <537A5429.4030002@amacapital.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> <1362600428.9953784.1400586583268.JavaMail.zimbra@redhat.com> Date: Tue, 20 May 2014 06:25:44 -0700 Message-ID: From: Watson Ladd To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Mo8chIJo8NsnOsM6ug4uz5Tcqm8 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 13:25:47 -0000 On Tue, May 20, 2014 at 4:49 AM, Hubert Kario wrote: > ----- Original Message ----- >> From: "Rich Salz" >> To: "Martin Thomson" , "Adam Langley" >> Cc: tls@ietf.org, "Andy Lutomirski" >> Sent: Monday, May 19, 2014 11:21:10 PM >> Subject: Re: [TLS] Simplifying the record protocol >> >> > Yes, I heard several people complaining about the size of keys in a post >> > quantum computing world. >> >> Handling post-quantum is a design requirement of TLS 1.3? > > Don't think so, but if not only all the algorithms but all the protocols > will have to be scrapped too, it won't make our future lives any easier. > > This would also make it a rather surprising regression compared to TLS 1.2 There are two impacts PQ has. The first is doubling the size of block cipher keys due to Grover's algorithm. I don't know off the top of my head what to do about hashes: its either triple the size or double. But this we can deal with. The second impact is encryption with small keys is based on NTRU, so keys are not that big. Signatures on MVQ variants like HFE+ or Quartz have short signatures: 128 bits for 128 bits of security. However, they have big keys: Quartz has a public key of approximately 2^21 bits. Certificate chains will feel the squeeze the most: we shouldn't reduce their size if we want TLS 1.3 (or TLS 1.0 even) to last into the PQ era. Perfect forwards secrecy needs some cleverness to ensure. Parameters are less well understood then in the classical case. Sincerely, Watson Ladd > > -- > Regards, > Hubert Kario > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue May 20 07:31:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7CD1A06F4 for ; Tue, 20 May 2014 07:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxR9rOF1_4ux for ; Tue, 20 May 2014 07:31:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4451A0346 for ; Tue, 20 May 2014 07:31:13 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4KEVA54013250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 May 2014 10:31:10 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4KEV7RP024861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 May 2014 10:31:09 -0400 Message-ID: <1400596267.20356.20.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Andy Lutomirski Date: Tue, 20 May 2014 16:31:07 +0200 In-Reply-To: <537A5429.4030002@amacapital.net> References: <537A5429.4030002@amacapital.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6EyjjiCqmtr2rUE3L2RTLFp9W-M Cc: tls@ietf.org Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:31:14 -0000 On Mon, 2014-05-19 at 11:57 -0700, Andy Lutomirski wrote: > This is inspired ekr mentioning removing some redundant fields and by a > discussion at the interim meeting about some TLS padding tricks that > won't work unless the record type is encrypted. Regardless of the > actual motivation, it should be both a cleanup and an efficiency > improvement. Keep in mind that by cleaning up and simplifying parts of a complex protocol, means that current implementations will not be simpler, but even more complex as they will have to additionally support the new options. While theoretically you could have a TLS 1.3-only implementation that could be simpler, in practice you will not. regards, Nikos From nobody Tue May 20 09:56:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20331A014D for ; Tue, 20 May 2014 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFVk3tvdDyQM for ; Tue, 20 May 2014 09:56:48 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D6B1A00E9 for ; Tue, 20 May 2014 09:56:48 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id rd3so495782pab.21 for ; Tue, 20 May 2014 09:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d/XW5zFagtfKgJ9fpYiDULncss/jTmT4SiHpBNoW0u0=; b=xDV3hb7YCiaP4vP2hiy5PgzFKl6eQ3WQuGBy6NNG3vLx9yvxGXY649RbswrMXFZwp6 XR9YBN0CZwdtwF6nRWW7tB27gCZM0QPznPqu+M4a/GBq5xh6o+LX23ZpUUvKBlpE1Wnl R/c2+oykmZWmmcx/m0TPNQ26kuMfAlv/TE8udvkgFOufp5aI0S0U3hOxoI/MHiVQUvtK s8NkPAylzc8kbFnzzTVlnmMeMMutDSpF63WGySUKZqhbukFQXq+Efbcxu+KL6b6stKi/ kKMgC2heZ0uMkpS/+qdqzZCiA9CCSR0HNmVd6bh+kKQIIXQwiO0q0bb27QB31e5j9GLL uRbQ== X-Received: by 10.66.171.138 with SMTP id au10mr18291663pac.102.1400605008336; Tue, 20 May 2014 09:56:48 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id qw8sm4010616pbb.27.2014.05.20.09.56.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 09:56:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Tue, 20 May 2014 09:56:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> <15d5a50ed2244e8595edfa57d7055e2b@BY2PR03MB554.namprd03.prod.outlook.com> To: Brian Sniffen Archived-At: http://mailarchive.ietf.org/arch/msg/tls/awjsdQfy4mTWVpI8Sxti1l4zYaM Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 16:56:50 -0000 > On May 15, 2014, at 8:05, Brian Sniffen wrote: >=20 > Marsh Ray writes: >=20 >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Brian Sniffen >>>=20 >>> Bitcoin's also hard to check: if the client says it found no bitcoin in a= >>> particular region, how do you know? And a whole bitcoin's too >>> much to ask. >>>=20 >>> An identity scheme tied to giving away bitcoin---much like a credit >>> rating ties to many transactions profitable for the counterparty--- >>> has a lot in its favor. It would make a great (research) extension >>> on top of TLS 1.3, and I hope that any puzzle mechanism will be >>> flexible enough to support that. >>=20 >> Years back, Microsoft was looking into a proof-of-work scheme for antispa= m sender-pays email. >> http://research.microsoft.com/en-us/projects/pennyblack/ >=20 > Thanks! I hadn't remembered the name, but that work was surely on my > mind as I wrote. >=20 >> One challenge is that botnets (that are conduits for most of the spam) al= so have plenty of spare CPU capacity. >=20 > Yes, but each bad node's CPU capacity only outstrips many good node's > capacities by a little bit---compared to network bandwidth, where very > often botnets outstrip good nodes' capacity by orders of magnitude. Of > course the bad nodes will beat out cell phone CPUs; a client puzzle > scheme has to be about, in some part, "acceptable losses." If we can > drop new mobile nodes and the botnet, but keep service up for (say) > established connections and "real" computers, that may be okay. I don't have hard data at hand, but my guess is that these days TLS connecti= ons from mobile devices far outnumber TLS connections from "real" computers.= So that may not be okay.=20 >=20 > -Brian >=20 > --=20 > Brian Sniffen > Information Security > Akamai Technologies >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 20 10:17:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7110D1A01A5 for ; Tue, 20 May 2014 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR8KIlgaTvrp for ; Tue, 20 May 2014 10:17:19 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561F11A0386 for ; Tue, 20 May 2014 10:17:19 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so1219157qcv.33 for ; Tue, 20 May 2014 10:17:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7o6R8K6Ty/bK3/gQVjH4qGlTmW89ybDQAJFLr8eVSXw=; b=IdLO8AY6AZtPtna/hfm85QNCnoyqJOf2X3ugVoqicMNWa+oIXatXdVAgSE7WBbinbJ FIyXry5Qfz7/E6WU0D/FaHlI0SWs3DwbjyiMbVkL6g8vFzDD7Ak/9BYkVcwNam2gLUkO Gg5K6h9CKARLjyzLIUA66931yhceEChhNWVUbKE6rPPP4poZ9aci5/i1FfhJDZBBiwUC LASVVHprlg2eXodQq/Ft/RvEaBXpoP+r/WfkUeEV2zdn2DX0tDcHwhIM3q24hc5pNUlF irDoJUNehQexxy/mtz7bVVLNAhhCPnpORJ5IJ4FXwfM2vyYAW/tSNo7SKbKWTn3zrcRD f+/g== X-Gm-Message-State: ALoCoQlrYojdn8AczLZkGQfmJSnZbYYqgMiVcltoLiF1EYB5WXb7h+PWxP0CJlnLV0NTvnOBKH7X MIME-Version: 1.0 X-Received: by 10.140.107.67 with SMTP id g61mr58416928qgf.100.1400606238179; Tue, 20 May 2014 10:17:18 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Tue, 20 May 2014 10:17:17 -0700 (PDT) X-Originating-IP: [109.201.138.210] In-Reply-To: <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> Date: Tue, 20 May 2014 17:17:17 +0000 Message-ID: From: Jacob Appelbaum To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KE8eDYqUgFuLKf6TaHWcbBRdN8Y Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:17:21 -0000 On 4/25/14, Martin Rex wrote: > Russ Housley wrote: >> > I think Rich Salz has outlined very compelling reasons not to support >> > SNI. >> >> While I might quibble with a detail here or there, I do agree with the >> conclusion. If you need to protect SNI, then TOR or to a lesser extent >> TLS-in-TLS can be used. > > I agree. If you need TOR, you should use TOR. > This is curious - what specific property do you think you need from Tor? To protect from information leaks in TLS or other protocols? If so, sure, use Tor. One doesn't need the anonymity of Tor or the censorship circumvention of Tor per se - rather, this is basically compensating for a protocol that leaks plaintext information. However - I wonder why not fix the (transport layer security) protocol to not have such an information leak? Then we can say: If you need anonymity, use Tor. If you need Transport Layer Security (and thus confidentiality), use TLS! This is also a conundrum for Tor I might add - we use TLS on the wire and as a result, we generate random stuff for say, the hostname embedded in various bits of the TLS connection. It would be nice if we could remove such distinguishers from the TLS protocol entirely. It would help Tor which is also useful, if as you say, you want people to use it when they need it. ( Also - It's Tor, not TOR. ) > Encrypted SNI comes at a huge cost, and could at best provide > a benefit somewhere between completely negligible and absolutely none. I'm not convinced that this is the right framing of the issue. Allow me to turn this over: Plaintext information leaks in TLS come at a huge cost and ensure that TLS may be selectively and actively attacked in a targeted manner. This is a protocol failure and we should correct it. > > Whether the service provider uses multiple services on a host at > all, is up to the service provider. > > What name the service provider chooses is up to the service provider. > > Whether the content of the individual hosts is (close to) 100% > distinguishable by its traffic patterns is up to the hosting provider, > the service providers, the nature of their contents and the amount > of (or lack of) cooperation/synchronization among the service providers. > > > It would be crazy if any of the secret three agencies would spent > a huge amount of protective efforts so that they could refer to > their "secret hideout at 17, umpteen street" under the term > "secret hideout at 17, umpteen street", instead of simply > calling it an office or a laundry, or whatever. > My concern is not helping secret three agencies. My concern is that those secret three agencies are attacking TLS. They use this distinguisher, as well as others, to select specific traffic for collection, as well as for censorship and other forms of exploitation. This applies to those agencies amongst other attackers who aren't well funded. We should consider this reality and try to defend against this threat. > > The server name is simply routing information. And it is not just > load-balancers that may want to be able to use that information > without having to open/terminate/participate the TLS communication, > it's also easier and cleaner for implementations at the endpoint > to do the server-side of TLS extension SNI "outside" of the TLS stack. > Sure - the server name is a distinguisher which serves as a way for attackers to exploit other issues in common TLS deployments. We should remove as many of the distinguishers from TLS in the client and server as is possible. We can't solve every traffic analysis problem with TLS but we don't need to leak the client's clock, the requested hostname, and lots of other details merely because we've always done so. I think that TLS in TLS is a nice idea but the outer handshake will still have distinguishers that ensure that such handshakes will be easy to deny selectively. The design of OTR is useful to consider. It doesn't make sense to simply declare TLS in TLS without considering how that would really look on the wire to an adversary with moderate DPI capabilities. All the best, Jacob From nobody Tue May 20 12:37:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1481A0217 for ; Tue, 20 May 2014 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-1SjCQdPA_a for ; Tue, 20 May 2014 12:36:58 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AF01A019B for ; Tue, 20 May 2014 12:36:57 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s4KJatHo012112; Tue, 20 May 2014 12:36:55 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1ky77fs1m6-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 May 2014 12:36:55 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 20 May 2014 12:36:52 -0700 From: Paul Lambert To: Jacob Appelbaum , "mrex@sap.com" Date: Tue, 20 May 2014 12:38:58 -0700 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac90YtlN0VCVsbvXT+WEpHpsth512A== Message-ID: References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-20_05:2014-05-20,2014-05-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405200239 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KIkZz6gAWwCCzJdrosdAVovQuUo Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 19:36:59 -0000 On 5/20/14, 10:17 AM, "Jacob Appelbaum" wrote: >On 4/25/14, Martin Rex wrote: >> Russ Housley wrote: >>> > I think Rich Salz has outlined very compelling reasons not to support >>> > SNI. >>> >>> While I might quibble with a detail here or there, I do agree with the >>> conclusion. If you need to protect SNI, then TOR or to a lesser extent >>> TLS-in-TLS can be used. >> >> I agree. If you need TOR, you should use TOR. >> > >This is curious - what specific property do you think you need from Tor? > >To protect from information leaks in TLS or other protocols? If so, >sure, use Tor. > >One doesn't need the anonymity of Tor or the censorship circumvention >of Tor per se - rather, this is basically compensating for a protocol >that leaks plaintext information. > >However - I wonder why not fix the (transport layer security) protocol >to not have such an information leak? Then we can say: If you need >anonymity, use Tor. If you need Transport Layer Security (and thus >confidentiality), use TLS! > >This is also a conundrum for Tor I might add - we use TLS on the wire >and as a result, we generate random stuff for say, the hostname >embedded in various bits of the TLS connection. It would be nice if we >could remove such distinguishers from the TLS protocol entirely. It >would help Tor which is also useful, if as you say, you want people to >use it when they need it. > >( Also - It's Tor, not TOR. ) > >> Encrypted SNI comes at a huge cost, and could at best provide >> a benefit somewhere between completely negligible and absolutely none. > >I'm not convinced that this is the right framing of the issue. Allow >me to turn this over: > >Plaintext information leaks in TLS come at a huge cost and ensure that >TLS may be selectively and actively attacked in a targeted manner. >This is a protocol failure and we should correct it. +1 Anonymity is easiest in a crowd. The same protocol exchanges used for everyday browsing should look identical to traffic requiring more careful protection. Proxied or onion routed traffic should appear identical to traffic destined to a visible end point. Paul > >> >> Whether the service provider uses multiple services on a host at >> all, is up to the service provider. >> >> What name the service provider chooses is up to the service provider. >> >> Whether the content of the individual hosts is (close to) 100% >> distinguishable by its traffic patterns is up to the hosting provider, >> the service providers, the nature of their contents and the amount >> of (or lack of) cooperation/synchronization among the service providers. >> >> >> It would be crazy if any of the secret three agencies would spent >> a huge amount of protective efforts so that they could refer to >> their "secret hideout at 17, umpteen street" under the term >> "secret hideout at 17, umpteen street", instead of simply >> calling it an office or a laundry, or whatever. >> > >My concern is not helping secret three agencies. My concern is that >those secret three agencies are attacking TLS. They use this >distinguisher, as well as others, to select specific traffic for >collection, as well as for censorship and other forms of exploitation. >This applies to those agencies amongst other attackers who aren't well >funded. We should consider this reality and try to defend against this >threat. > >> >> The server name is simply routing information. And it is not just >> load-balancers that may want to be able to use that information >> without having to open/terminate/participate the TLS communication, >> it's also easier and cleaner for implementations at the endpoint >> to do the server-side of TLS extension SNI "outside" of the TLS stack. >> > >Sure - the server name is a distinguisher which serves as a way for >attackers to exploit other issues in common TLS deployments. We should >remove as many of the distinguishers from TLS in the client and server >as is possible. We can't solve every traffic analysis problem with TLS >but we don't need to leak the client's clock, the requested hostname, >and lots of other details merely because we've always done so. > >I think that TLS in TLS is a nice idea but the outer handshake will >still have distinguishers that ensure that such handshakes will be >easy to deny selectively. The design of OTR is useful to consider. It >doesn't make sense to simply declare TLS in TLS without considering >how that would really look on the wire to an adversary with moderate >DPI capabilities. > >All the best, >Jacob > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 20 13:02:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E986F1A03C6 for ; Tue, 20 May 2014 13:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlqfHk_nGk71 for ; Tue, 20 May 2014 13:02:21 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94BC1A03B4 for ; Tue, 20 May 2014 13:02:20 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so1019176wgh.11 for ; Tue, 20 May 2014 13:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wzfxCPCzOq2YVMS7KrpTbkh6LyvJ0I47AtB1sHJmv2o=; b=ceEzcZaeqKHN5nE92ROsV/KdhtsU2TOSnCWc1FAJaBEm4us0nFdHsFFlVgStZ35nTR yuyaJGud6WEp+ERuZ6239XOqO9YvTp3/ryj4W2z6XPsaoRfyUJL4m8UvrWJfGSYR9Ufw 2QlIy1gBBupGB7gilJWJ+a5wrFhrooVQESxUCYFo6vxSv1n1AevStpal20ba+UxIenos o0qbbS9W4VH7tUyZ9NZaaTwcRWrF3QN982wQ4bSsygjPVHloN3QGUI/E6KRKaru5PAco RsP20TwttY9RZSwHH83kECiEN1WFtzAyf9r+FJvYhnxnFUfnTXG2FZZbUMd2Dr174t7t FyMw== X-Received: by 10.194.177.131 with SMTP id cq3mr18902327wjc.23.1400616139147; Tue, 20 May 2014 13:02:19 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id hr4sm19601487wjb.28.2014.05.20.13.02.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 13:02:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D6594574-D07D-4535-8303-1F6349BB60C6" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Tue, 20 May 2014 23:02:15 +0300 Message-Id: References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> To: Jacob Appelbaum X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1zqBB4v6Kj-Zl22gckvuKqLSUR4 Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:02:23 -0000 --Apple-Mail=_D6594574-D07D-4535-8303-1F6349BB60C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 20, 2014, at 8:17 PM, Jacob Appelbaum = wrote: > On 4/25/14, Martin Rex wrote: >> Russ Housley wrote: >>>> I think Rich Salz has outlined very compelling reasons not to = support >>>> SNI. >>>=20 >>> While I might quibble with a detail here or there, I do agree with = the >>> conclusion. If you need to protect SNI, then TOR or to a lesser = extent >>> TLS-in-TLS can be used. >>=20 >> I agree. If you need TOR, you should use TOR. >>=20 >=20 > This is curious - what specific property do you think you need from = Tor? >=20 > To protect from information leaks in TLS or other protocols? If so, > sure, use Tor. >=20 > One doesn't need the anonymity of Tor or the censorship circumvention > of Tor per se - rather, this is basically compensating for a protocol > that leaks plaintext information. The requirement for encrypted SNI is very simple. I want to browse = certain web sites such that if people knew I was browsing them it might = get me in trouble. We all like the example of a gay teenager in Uganda, = but it could just as well be an American browsing a website advocating = Shari=92a law for all western countries landing in a no-flight list. Encrypting SNI would help if the =93suspicious=94 web site is hosted by = a hosting service, and there are multiple innocuous sites on the same IP = address, and the traffic from the innocuous sites dominates the traffic = to the server, and traffic for this site is not distinguishable by other = means such as traffic analysis. That=92s a lot of =91if=92s up there, = and if any of them fails, the adversary will know that I browsed the = suspicious site. AFAIK Tor provides a far more robust protection of this = kind of activity. So I=92m with Martin on this. If you need Tor, use Tor. Yoav --Apple-Mail=_D6594574-D07D-4535-8303-1F6349BB60C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 20, 2014, at 8:17 PM, Jacob = Appelbaum <jacob@appelbaum.net> = wrote:

On 4/25/14, Martin Rex <mrex@sap.com> wrote:
Russ Housley wrote:
I think Rich Salz has outlined very compelling reasons = not to support
SNI.

While I might quibble with a = detail here or there, I do agree with the
conclusion.  If you = need to protect SNI, then TOR or to a lesser extent
TLS-in-TLS can be = used.

I agree.  If you need TOR, you should use = TOR.


This is curious - what specific property do = you think you need from Tor?

To protect from information leaks in = TLS or other protocols? If so,
sure, use Tor.

One doesn't need = the anonymity of Tor or the censorship circumvention
of Tor per se - = rather, this is basically compensating for a protocol
that leaks = plaintext information.

The = requirement for encrypted SNI is very simple. I want to browse certain = web sites such that if people knew I was browsing them it might get me = in trouble. We all like the example of a gay teenager in Uganda, but it = could just as well be an American browsing a website advocating Shari=92a = law for all western countries landing in a no-flight = list.

Encrypting SNI would help if the = =93suspicious=94 web site is hosted by a hosting service, and there are = multiple innocuous sites on the same IP address, and the traffic from = the innocuous sites dominates the traffic to the server, and traffic for = this site is not distinguishable by other means such as traffic = analysis.  That=92s a lot of =91if=92s up there, and if any of them = fails, the adversary will know that I browsed the suspicious site. AFAIK = Tor provides a far more robust protection of this kind of = activity.

So I=92m with Martin on this. If you = need Tor, use = Tor.

Yoav

= --Apple-Mail=_D6594574-D07D-4535-8303-1F6349BB60C6-- From nobody Tue May 20 13:18:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5E1A0743 for ; Tue, 20 May 2014 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js90a-Hnst_c for ; Tue, 20 May 2014 13:18:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD8B11A072D for ; Tue, 20 May 2014 13:18:29 -0700 (PDT) Received: from [10.70.10.78] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A8D24F984 for ; Tue, 20 May 2014 16:18:26 -0400 (EDT) Message-ID: <537BB889.3040000@fifthhorseman.net> Date: Tue, 20 May 2014 16:18:17 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: IETF TLS References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fVS4SH1qs9VeKcf1okCru6wsrn6dAAbAS" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M-EcSFkivuWe4eDbEhmdE6e-9Ro Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:18:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fVS4SH1qs9VeKcf1okCru6wsrn6dAAbAS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/20/2014 04:02 PM, Yoav Nir wrote: > The requirement for encrypted SNI is very simple. I want to browse cert= ain web sites such that if people knew I was browsing them it might get m= e in trouble. We all like the example of a gay teenager in Uganda, but it= could just as well be an American browsing a website advocating Shari=E2= =80=99a law for all western countries landing in a no-flight list. >=20 > Encrypting SNI would help if the =E2=80=9Csuspicious=E2=80=9D web site = is hosted by a hosting service, and there are multiple innocuous sites on= the same IP address, and the traffic from the innocuous sites dominates = the traffic to the server, and traffic for this site is not distinguishab= le by other means such as traffic analysis. That=E2=80=99s a lot of =E2=80= =98if=E2=80=99s up there, and if any of them fails, the adversary will kn= ow that I browsed the suspicious site. AFAIK Tor provides a far more robu= st protection of this kind of activity. I agree that it is a lot of 'if's, and you didn't even mention DNS privacy, or running a non-compromised web browser, or client operating system security, or whether the "risky" services are running on untrustworthy cloud infrastructure, or if they log user traffic via popular analytics services which themselves could be compromised, or if the user isn't clearing their browsing history, etc. I'm sure we can come up with many more problems that could give away the association between the user and the web site unrelated to either Tor or TLS. But the fact that other problems and constraints exist is a terrible reason to avoid fixing the constrained problems we *can* fix in the protocol we are responsible for. --dkg --fVS4SH1qs9VeKcf1okCru6wsrn6dAAbAS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTe7iJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcNUMP/0tSey2UKn6UEXHCdkGEgHzz FaJ02VuXwgHw+s25uqj+E579imwYsee8Io7NCOnybiVxkkt6Oks0f72hTG6wYTcs gxkbtxhvCE1HLJpO0307jQ82WFMfbKr56YITR3jTQa0jnQARsBxBe0nd0mxuedOz BR2ecsr6cXgFLt1IWVuOLQOYm00cDXtcMDy2hwzv2vZlK5shtRQYDcaKktZ8V6KV saLHmX9o/9ZG5b9hEE2zooaS6D70RjZDPo7Ud/6VMUSWIjBtaumcjSYK0X2+exYC 7YhtfZWyX5T4RfnYR255EA9mfnFqgB9GCuPl7N4izk+u2MWt27qHCeM0IzrsO6+X PrQrj9hp8CRIrwopX/QqJXyQHH2Vi+Qf52uf4Ucpfb/2pjvNabzjcGsqAckVZCHo jiQuBEX/Uqtn0OpbKpFWHCmwrM/kvaAP09nvlTQ451p+fDEgKyWMFQ9osneMwbbI PunU0gKpTjBjcqugQVxxZjskL/Sx9VvlJbB1fwqpt172pb8CLo8gyJgShZd+ivnk zb/dbjgH8B9NrgPF/QlEMTsVyFGGhJz/W9SfGCt+uSKbUy1UNP3tk275iopF09s3 nR5Aqq+KJKmbgg7RSJ/yfMa9dboK6U8pdcxZ1p8Cue5C1+QB4phW/eYR6sTNPRLi SxxhIldm44U7E4Hl7lql =FLlQ -----END PGP SIGNATURE----- --fVS4SH1qs9VeKcf1okCru6wsrn6dAAbAS-- From nobody Tue May 20 13:24:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8AA1A0758 for ; Tue, 20 May 2014 13:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVqN5daTI7VT for ; Tue, 20 May 2014 13:24:33 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E521A072D for ; Tue, 20 May 2014 13:24:33 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id db11so1315465veb.29 for ; Tue, 20 May 2014 13:24:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bDnPyYO9+w4RIi/M7RWAw2p84y+DISMMDIErOgUSTqM=; b=HzxX730A4R3/2x19E/pxXaUnwwleEawnvALjms3eDbMVPz/G0pMGmPbR8lPq+x/ncB 7nSmFpltihTBnB8RML8nEmdbn8V+BfLwE0qTuhDy6CXbLwQQDgBIBABn+dHs1SyPB6/s 9yIPfgilhPlNW85ZMJaNf3thrwrJs43yIsAP5P37OxNZ1iN5bpeFn3XcWSFR5zvdJPGm RoqR7HNXi0v99vGz6i3URxUP3exBd49VZmBPFN4pLofolzcL9NtyVBitECWMRWDtRvGo Vchk0N0KYoPWDmLIf9R466FruoKEI1R45J9SMKPN3sWdQDLEtpxXAnL5hEKT3MvT3OsD 4sow== X-Gm-Message-State: ALoCoQkV6xrStpbJ/PjllraIlGveWlhQa4byeyiifL/Hl4QJ1n/eH/dd5MW9fpRrX8v8aMUm5MQi X-Received: by 10.52.104.7 with SMTP id ga7mr4947206vdb.29.1400617472122; Tue, 20 May 2014 13:24:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Tue, 20 May 2014 13:24:12 -0700 (PDT) X-Originating-IP: [107.19.76.28] In-Reply-To: References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> From: Tim Bray Date: Tue, 20 May 2014 13:24:12 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a1136be72e475da04f9daaa0e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SUoTk3l8NX2JLw5QpZnCJYrAFys Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:24:35 -0000 --001a1136be72e475da04f9daaa0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 20, 2014 at 1:02 PM, Yoav Nir wrote: > > The requirement for encrypted SNI is very simple. I want to browse certai= n > web sites such that if people knew I was browsing them it might get me in > trouble. We all like the example of a gay teenager in Uganda, but it coul= d > just as well be an American browsing a website advocating Shari=E2=80=99a= law for > all western countries landing in a no-flight list. > > Encrypting SNI would help if the =E2=80=9Csuspicious=E2=80=9D web site is= hosted by a > hosting service, and there are multiple innocuous sites on the same IP > address, and the traffic from the innocuous sites dominates the traffic t= o > the server, and traffic for this site is not distinguishable by other mea= ns > such as traffic analysis. That=E2=80=99s a lot of =E2=80=98if=E2=80=99s = up there, and if any of > them fails, the adversary will know that I browsed the suspicious site. > AFAIK Tor provides a far more robust protection of this kind of activity. > Let=E2=80=99s assume you are correct in all your assertions. It is still t= he case that every time you increase the proportion of the attack surface which is encrypted, you increase the difficulty for snoopers. It is not a requirement that you make the snoopers=E2=80=99 task impossible; in fact, a= ll you can ever do is crank up the difficulty for attackers. It seems obvious that encrypting as much of connection setup as possible would increase attacker difficulty so, if practical, it should be done. > > So I=E2=80=99m with Martin on this. If you need Tor, use Tor. > > Yoav > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1136be72e475da04f9daaa0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Tue, May 20, 2014 at 1:02 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

The requi= rement for encrypted SNI is very simple. I want to browse certain web sites= such that if people knew I was browsing them it might get me in trouble. W= e all like the example of a gay teenager in Uganda, but it could just as we= ll be an American browsing a website advocating Shari=E2=80=99a law for all= western countries landing in a no-flight list.

Encrypting SNI would help if the =E2=80=9Cs= uspicious=E2=80=9D web site is hosted by a hosting service, and there are m= ultiple innocuous sites on the same IP address, and the traffic from the in= nocuous sites dominates the traffic to the server, and traffic for this sit= e is not distinguishable by other means such as traffic analysis. =C2=A0Tha= t=E2=80=99s a lot of =E2=80=98if=E2=80=99s up there, and if any of them fai= ls, the adversary will know that I browsed the suspicious site. AFAIK Tor p= rovides a far more robust protection of this kind of activity.

Let=E2=80=99s assume you are correct in all your asser= tions. =C2=A0It is still the case that every time you increase the proporti= on of the attack surface which is encrypted, you increase the difficulty fo= r snoopers. It is not a requirement that you make the snoopers=E2=80=99 tas= k impossible; in fact, all you can ever do is crank up the difficulty for a= ttackers. It seems obvious that encrypting as much of connection setup as p= ossible would increase attacker difficulty so, if practical, it should be d= one.



=C2=A0

So I= =E2=80=99m with Martin on this. If you need Tor, use Tor.

Yoav


__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls




--
- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)
--001a1136be72e475da04f9daaa0e-- From nobody Tue May 20 13:47:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A061A07A4 for ; Tue, 20 May 2014 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDvpC6fYo9Fq for ; Tue, 20 May 2014 13:47:13 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F55E1A0797 for ; Tue, 20 May 2014 13:47:13 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so1749008qgd.1 for ; Tue, 20 May 2014 13:47:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j33hj7hYde3r5XfoNenMjjXM9ADUlaEdHdiwbZQUZ/o=; b=hEe3npJYZQ3ire+DPOqZpW/DHUVkg4LGYTjNuLKx2HvwJ8w+Cn2qWY8LG6KH/NlGZm L2CdsBiaeLpQSySlTjH90HCRfAbYCJEVfWq3Yp6HT1MtutyFcP1rvZ6kAHgpq4tHsZpW 7hdzpWGHtRFZPwTe6byr+AgXWldlBExVFHsmiIiA9CCf7rUllt0U42BuC+UwVsofvXL6 Ka8M3MRUxrw7HLLw472MfWkh1wW3WRxBzyMelMTpS/mvTqozVh6mLPONYRzVTFTrV4U7 9i/OLuFm1BMawKY02VODUFY5osPt5UDV7aehBTW8LmfcBnDy2PXLygEmfWxvyLE1J+SS yAYw== X-Gm-Message-State: ALoCoQn9J/x5QTKufVDJ4sBm4gl+0iNY9BeUnYKH2ehPtSL16ZP/lu+dEqPGiRslxyDRK/Q4ucCS MIME-Version: 1.0 X-Received: by 10.224.66.74 with SMTP id m10mr61939606qai.14.1400618832200; Tue, 20 May 2014 13:47:12 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Tue, 20 May 2014 13:47:12 -0700 (PDT) X-Originating-IP: [37.148.163.38] In-Reply-To: References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> Date: Tue, 20 May 2014 20:47:12 +0000 Message-ID: From: Jacob Appelbaum To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FTldOxhioT5muvSE-owZX8X7Hjo Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:47:14 -0000 On 5/20/14, Yoav Nir wrote: > > On May 20, 2014, at 8:17 PM, Jacob Appelbaum wrote: > >> On 4/25/14, Martin Rex wrote: >>> Russ Housley wrote: >>>>> I think Rich Salz has outlined very compelling reasons not to support >>>>> SNI. >>>> >>>> While I might quibble with a detail here or there, I do agree with the >>>> conclusion. If you need to protect SNI, then TOR or to a lesser exten= t >>>> TLS-in-TLS can be used. >>> >>> I agree. If you need TOR, you should use TOR. >>> >> >> This is curious - what specific property do you think you need from Tor? >> >> To protect from information leaks in TLS or other protocols? If so, >> sure, use Tor. >> >> One doesn't need the anonymity of Tor or the censorship circumvention >> of Tor per se - rather, this is basically compensating for a protocol >> that leaks plaintext information. > > The requirement for encrypted SNI is very simple. I want to browse certai= n > web sites such that if people knew I was browsing them it might get me in > trouble. We all like the example of a gay teenager in Uganda, but it coul= d > just as well be an American browsing a website advocating Shari=E2=80=99a= law for > all western countries landing in a no-flight list. TLS is about protecting things more than websites, isn't it? Or put another way: the internet is more than the world wide web! My requirement for encrypting SNI is different than yours, I suppose. I want to stop information leaks that are used by attackers to degrade or otherwise attack users of TLS. I also want to stop a passive attacker from learning specific details about my TLS session. I also want to ensure that I can detect an active attacker who wishes to learn this information before I might disclose it. Leaking information automatically for every connection to a passive attacker doesn't meet those requirements. > > Encrypting SNI would help if the =E2=80=9Csuspicious=E2=80=9D web site is= hosted by a > hosting service, and there are multiple innocuous sites on the same IP > address, and the traffic from the innocuous sites dominates the traffic t= o > the server, and traffic for this site is not distinguishable by other mea= ns > such as traffic analysis. That=E2=80=99s a lot of =E2=80=98if=E2=80=99s = up there, and if any of > them fails, the adversary will know that I browsed the suspicious site. That is largely false, I think, There are many kinds of adversaries. As it stands, we're not even able to defend against attackers who can just watch a handshake. They can even perform a selective MITM before the handshake completes. We're not even into website fingerprinting techniques, which yes, I agree are a problem. Such fingerprinting issues are however a different problem in a family of problems, frankly. It is clear that TLS cannot protect you from practical realities about information theory. It would be nice if that was actually the issue at hand. Rather we're discussing an information leak that largely comes from a trend of centralization. E.g: we have a lot of hostnames on one IP address or a cluster of load balancers handling a bunch of different sites. As a result, we need to reveal the hostname to ensure that the server returns the correct certificate. Obviously, we need to reveal that information somewhere, I just don't buy that we should reveal it to the network. TLS should protect you from this information disclosure. Users that I have asked were surprised to learn that TLS reveals the hostname in their TLS connection. I think a good quote is: "What does that padlock even mean?!?" Amusing, right? Well, perhaps... but what does the security in TLS mean anyway? If it means leaking information everywhere so that more people are motivated to use Tor, what should Tor use as a transport protocol when it wants confidentiality? Not TLS? ... Argh. > AFAIK Tor provides a far more robust protection of this kind of activity. > Tor relies on TLS and does not have the problem that say, a CDN has with virtual hosting. And in any case, these choices in TLS will ensure that it is harder for Tor to provide needed robust protection for any activity. A Tor bridge, for example, is not listed in a public directory. The TLS distinguishers are what make it easy for a passive adversary to tag (say, with XKEYSCORE) those flows for further analysis. In the case of China and Iran, we see this analysis in the form of automated detection of bridges, where the censors actively probe suspect connections and then blackhole traffic when they feel it is positively a Tor bridge. This does not happen for all TLS connections and it would probably not currently scale for all TLS connections. If we could blend in, we'd be better off. We have an obfuscated protocol for defeating DPI but man, that is a hard road and in any case, it makes some assumptions that are (likely) wrong. It is hard to close that feedback loop without censorship - that is - sometimes the only detection of surveillance (aka our friend Eve) is with censorship. Which brings me to the case of the FVEY countries (UK, US, CA, NZ, AU) and their other partner nations (a longer list including SE, DE, etc - look it up) - they use XKEYSCORE to tag TLS traffic based on these distinguishers. That data is put into databases for later uses. It is also used for exploitation ala QUANTUM*. These TLS issues are really a problem and they are really being actively exploited in the wild. > So I=E2=80=99m with Martin on this. If you need Tor, use Tor. > And how will you get your copy of Tor, exactly? And how will you use that on devices where there is no Tor? And when you download your copy of Tor, what happens to the meta-data about those traffic flows? I guess it should be easy to pick out torproject.org from the SNI flowing across our TLS enabled website, regardless of all the other protections we might take... None of our TLS sessions are free (from surveillance and censorship) until they're all free (of distinguishers)... :-) All the best, Jacob From nobody Tue May 20 13:58:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C996A1A0156 for ; Tue, 20 May 2014 13:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKAjqYPORu-J for ; Tue, 20 May 2014 13:58:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214901A00B1 for ; Tue, 20 May 2014 13:58:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s4KKwc8l059164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 May 2014 13:58:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Tue, 20 May 2014 13:58:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69E192DD-4953-4D89-81C8-5A34006EBF3C@vpnc.org> References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> To: IETF TLS X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UU4n_PwQ20xw-8i2vQAbX7hX_4w Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:58:41 -0000 On May 20, 2014, at 1:24 PM, Tim Bray wrote: > Let=92s assume you are correct in all your assertions. It is still = the case that every time you increase the proportion of the attack = surface which is encrypted, you increase the difficulty for snoopers. It = is not a requirement that you make the snoopers=92 task impossible; in = fact, all you can ever do is crank up the difficulty for attackers. It = seems obvious that encrypting as much of connection setup as possible = would increase attacker difficulty so, if practical, it should be done. The question for the WG is the "if practical" part of that sentence. = Among all the proposals for encrypting SNI, there are different = practicality tradeoffs (additional round trips, worse downgrade = susceptibility, needing to get additional information from the DNS, = ...). Different people will have different measurements of practicality, = which means that any change we make here will end up making TLS 1.3 less = practical for someone. Deciding who that should be will be based on the = proposals themselves. --Paul Hoffman= From nobody Tue May 20 14:40:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB31A03AB for ; Tue, 20 May 2014 14:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME9Xungmz-ti for ; Tue, 20 May 2014 14:40:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6D41A02BC for ; Tue, 20 May 2014 14:40:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 82BFB2AB10D; Tue, 20 May 2014 21:40:36 +0000 (UTC) Date: Tue, 20 May 2014 21:40:36 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140520214036.GF27883@mournblade.imrryr.org> References: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/40KyWSsZXP6JYYbcG_0ySpBu9cc Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 21:40:40 -0000 On Tue, May 20, 2014 at 01:24:12PM -0700, Tim Bray wrote: > Let?s assume you are correct in all your assertions. It is still the case > that every time you increase the proportion of the attack surface which is > encrypted, you increase the difficulty for snoopers. It is not a > requirement that you make the snoopers? task impossible; in fact, all you > can ever do is crank up the difficulty for attackers. It seems obvious that > encrypting as much of connection setup as possible would increase attacker > difficulty so, if practical, it should be done. This runs smack into the "mile-high pole" fallacy. Quoting Bruce Schneier: Secure the Weakest Link You can't just plant a mile-high pole in front of your castle and hope the enemy runs right into it; you have to look at the whole landscape and build earthworks and a palisade. Similarly, just because you're using an encryption algorithm with a 256-bit key doesn't mean you're secure; the enemy is likely to find some avenue of attack ignores the encryption algorithm completely. In particular stronger security measures that focus on a small part of the problem often yield no measurable benefit. This is quite likely the case here. I would not want to encourage any user whose life or well-being depended on security of TLS against traffic analysis to even consider relying on TLS SNI encryption. Such users need to be substantially more cautious. The only plausible use-case for SNI encryption is to thwart bulk traffic analysis directed at entire populations, users likely to be targeted MUST NOT rely on protection as feeble as an encrypted TLS handshake might yield (yes, if it is possible at tolerable cost to not aid the attacker AND there is a reasonably plausible measurable benefit as a result, one should still implement the protection). So this boils down to whether: Is it in fact plausible that all the various counter-measures were they rolled out (over a decade or two), in multiple protocols and implementations, would provide the expected benefit by making traffic analysis measurably more difficult? I am regrettably skeptical of this. I think we could make more progress by obviating the need for SNI than by attempting to encrypt it. For example, with DNSSEC SRV records, the TLS service endpoint for a hosted domain can be mapped to a fixed hosting name that does not depend on the hosted domain name, and the client could verify the single name in the server certificate. If we move to an SNI-free world, the problem is eliminated from TLS. There are still DNS queries to protect, but these would need to be protected anyway (the A record lookup). Of course SNI is almost certainly not the only sensitive payload in the handshake, and one might want to define a stripped-down outer protocol that completes an ADH or AECDH key exchange with channel binding first to an SNI-agnostic TLS stack at the target, and then sub-negotiates with channel binding any additional protection that may be desired. Such a protocol would sport mandatory session tickets for fast reliable resumption, with a lifetime advertised to the client to avoid needless fallback latency to the full outer protocol. Resumption would begin with an outer session ticket and an encrypted inner handshake (which might also be a resumption). If outer resumption does fail (should be rare), the server would elicit a new full outer handshake from the client, without requiring the client to disconnect and retry. This would be a dramatic change, would one still call such a beast TLS? -- Viktor. From nobody Tue May 20 17:24:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372041A03DE for ; Tue, 20 May 2014 17:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHfLo663NBWq for ; Tue, 20 May 2014 17:24:25 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E3E1A03CC for ; Tue, 20 May 2014 17:24:25 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so807270pab.8 for ; Tue, 20 May 2014 17:24:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aDdvUW9FrRoNnNCvcwebNniQ6xzpiNa/+Vwg+3BShm4=; b=R9NautJkLv/FaVoPs+udT9Dmgk3bwneHwxQX+MnLNiriGRa9m58N+IN9b4HyC/2sIc sGUkfn78A4Lrb3CKla7blDGrYbBS6Bh2/v42MZj+tivhphr1dv/u2/jSAN4pToHT4I1a G3hM60Wp0cdROO3nUmzG2axxZ5jLsvcZrK+3ey2IjqpV+3bSso2P1oKhc+IXkgJC74aj Rwuz4kf431Rpqh7xzqHcNbqhteMFQlEV7at+OKrbum3RQYIuHC9FiGSkliVO5Y+OAkQN lNjSUOmDL9U1/VPQZ6v/QJsispicv+U7YdjTsda4hbPMGsJfvJmUX0wskG0Mtzy7DGpS 5udw== X-Gm-Message-State: ALoCoQnw+hE2Z2XFVKSyRJ5JWeQ27Qm5jZATvCOPA0JfDKKQJr0YAmc8ZqIRAJGlFyGFXzKj5chS X-Received: by 10.68.229.68 with SMTP id so4mr53758132pbc.110.1400631864738; Tue, 20 May 2014 17:24:24 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id hk5sm5050235pbb.86.2014.05.20.17.24.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 17:24:24 -0700 (PDT) Message-ID: <537BF236.5070506@amacapital.net> Date: Tue, 20 May 2014 17:24:22 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Watson Ladd , Hubert Kario References: <537A5429.4030002@amacapital.net> <2A0EFB9C05D0164E98F19BB0AF3708C7130AFC5EF3@USMBX1.msg.corp.akamai.com> <1362600428.9953784.1400586583268.JavaMail.zimbra@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NXUIoiq7TLY6sB7uDOGPOdINugQ Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 00:24:27 -0000 On 05/20/2014 06:25 AM, Watson Ladd wrote: > On Tue, May 20, 2014 at 4:49 AM, Hubert Kario wrote: >> ----- Original Message ----- >>> From: "Rich Salz" >>> To: "Martin Thomson" , "Adam Langley" >>> Cc: tls@ietf.org, "Andy Lutomirski" >>> Sent: Monday, May 19, 2014 11:21:10 PM >>> Subject: Re: [TLS] Simplifying the record protocol >>> >>>> Yes, I heard several people complaining about the size of keys in a post >>>> quantum computing world. >>> >>> Handling post-quantum is a design requirement of TLS 1.3? >> >> Don't think so, but if not only all the algorithms but all the protocols >> will have to be scrapped too, it won't make our future lives any easier. >> >> This would also make it a rather surprising regression compared to TLS 1.2 > > There are two impacts PQ has. The first is doubling the size of block > cipher keys due to Grover's algorithm. I don't know off the top of my > head what to do about hashes: its either triple the size or double. > But this we can deal with. The quantum complexity for general preimages is O(2^(n/2)) and for collisions is O(2^(n/3)) for an n-bit hash, assuming that there's nothing about the hash in question that allows attacks better than the best possible generic attacks. So doubling the size is fine. > > The second impact is encryption with small keys is based on NTRU, so > keys are not that big. Signatures on MVQ variants like HFE+ or Quartz > have short signatures: 128 bits for 128 bits of security. However, > they have big keys: Quartz has a public key of approximately 2^21 > bits. Certificate chains will feel the squeeze the most: we shouldn't > reduce their size if we want TLS 1.3 (or TLS 1.0 even) to last into > the PQ era. > > Perfect forwards secrecy needs some cleverness to ensure. Parameters > are less well understood then in the classical case. NTRUEncrypt can do it: one party generates an ephemeral key pair; the other party generates a session key and encrypts it. This doesn't allow both operations to happen at once the way that DH does, but this might not matter. A fancier approach preserves the property that neither party controls the key: Alice generates a key pair (pub, priv) Bob generates r, a random string Alice -> Bob: pub Bob -> Alice: Enc_pub(r) The session key is H(pub || r) for any PRF H. This can be dropped directly in to TLS where Enc_pub is the NTRUEncrypt primitive with any appropriate padding and where H is any PRF. Alice is whichever party is expected to send a DH share first and Bob is whichever party is expecdsted to send a DH share second. This also works if Enc_pub is any other public-key encryption algorithm with appropriate security properties. Of course, using McEliece here would be insane. Of course, this has all kinds of IPR issues. Under my extremely weak understanding of this stuff, the patents should expire some time in 2020. OTOH, it may actually pay to standardize this and to implement it in, say, GnuTLS, which can possibly use the existing patent license. In any event, I think that TLS should not lose the ability to support fairly long Handshake messages. --Andy From nobody Wed May 21 02:36:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC1B1A0320 for ; Wed, 21 May 2014 02:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WetU9Lfi0TYW for ; Wed, 21 May 2014 02:36:15 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8341A0315 for ; Wed, 21 May 2014 02:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1400664974; x=1432200974; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=exMUgculTs6LBQ2ExAYHZeJykKUIiZvy6Ijtu35i4to=; b=eFsJLK4ZQpkekyzSSxw/KBhSDMWRNia6kvSIK1XpBzBzulvZ9Sa20NIy W2AvPe7TSLv32ed8YFTiFu8uyK9+NHEVMjS+a7QyzxBUFAQbw+DhL4dSg C5ynsSf0BbRsesaWNuajnVbsZppdPgAhS0Zb7lWF0JectfhlwyegNAFzk 0=; X-IronPort-AV: E=Sophos;i="4.98,879,1392116400"; d="scan'208";a="253659833" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 May 2014 21:36:13 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.105]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Wed, 21 May 2014 21:36:12 +1200 From: Peter Gutmann To: "" Thread-Topic: Early codepoint assignment for encrypt-then-MAC Thread-Index: Ac902BpKxXw+iOPxTwCMon1L/hGwcQ== Date: Wed, 21 May 2014 09:36:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC237B5@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kwgmiWjuyitIfIVe1n0DkYAxwps Subject: [TLS] Early codepoint assignment for encrypt-then-MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 09:36:16 -0000 Since a number of implementations are already doing EtM, would it be possib= le=0A= to get an early codepoint assignment for this? This would make it less of = a=0A= moving target for people to code to.=0A= =0A= Peter.=0A= From nobody Wed May 21 05:37:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335261A05C3 for ; Wed, 21 May 2014 05:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMdA_rNe4iSJ for ; Wed, 21 May 2014 05:37:08 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA26C1A063B for ; Wed, 21 May 2014 05:37:03 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so1967548wgh.32 for ; Wed, 21 May 2014 05:37:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NsdiZrt4lkMAbkpl9PmdCr0pajy3yugDuK3+SbU61kg=; b=gP+eRQ6k2kRtjg7lW4QETtPeaq8QoKde9r3W6mis+Qv2ooxxPIbiQZujGvWHg3r2fS wvZ8PAc2RkhyFIqwKhiT+TkC8wKARC1v9Nlo5oHKmpcErQttxzuN7ZW57tLUnpy6OS4r fyd4TRg/0M+6872Nz+QMTXnJMYAnmRbX7Yjr84WgN2tcf5nPgFbVDfIjmHJeazYuagFI FYePUXtj/BGTecait2BmL4APoqyZ/Ai1QuDxKCXfc6hcKOHqGXWHc6UHx3p0ugippgQ1 j7rhJVGGJ1b9xhT2lnVPaf6wZDqlz3FkSj9AfZl+fIHElgw2jasW48YuMN8pZA7WVYpI Nclw== X-Gm-Message-State: ALoCoQlnazVk2XSlxCuc8DLR0o+140aPsNcEMNBJL900SW/nN/nKXWxj6/WjbqHTNchCKe8YJ8yb X-Received: by 10.180.13.209 with SMTP id j17mr10292495wic.18.1400675821844; Wed, 21 May 2014 05:37:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 21 May 2014 05:36:21 -0700 (PDT) X-Originating-IP: [216.239.55.62] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC237B5@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738AC237B5@uxcn10-tdc06.UoA.auckland.ac.nz> From: Eric Rescorla Date: Wed, 21 May 2014 05:36:21 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a11c2412ece946704f9e8404c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gHGAuohNRtR38TVorNXfUQ7qTHg Cc: "" Subject: Re: [TLS] Early codepoint assignment for encrypt-then-MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:37:11 -0000 --001a11c2412ece946704f9e8404c Content-Type: text/plain; charset=UTF-8 Thanks for reminder. The chairs will request it. -Ekr On Wed, May 21, 2014 at 2:36 AM, Peter Gutmann wrote: > Since a number of implementations are already doing EtM, would it be > possible > to get an early codepoint assignment for this? This would make it less of > a > moving target for people to code to. > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c2412ece946704f9e8404c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for reminder. The chairs will request it.

<= /div>
-Ekr


On Wed, May 21, 2014 at 2:36 AM, Peter Gutmann = <pgut001@cs.auckland.ac.nz> wrote:
Since a number of implementations are alread= y doing EtM, would it be possible
to get an early codepoint assignment for this? =C2=A0This would make it les= s of a
moving target for people to code to.

Peter.

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11c2412ece946704f9e8404c-- From nobody Wed May 21 11:19:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E951A037D for ; Wed, 21 May 2014 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA_vEdik-WTr for ; Wed, 21 May 2014 11:18:56 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 304AD1A033D for ; Wed, 21 May 2014 11:18:55 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A551A28525; Wed, 21 May 2014 18:18:54 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 936CE2851E; Wed, 21 May 2014 18:18:54 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 683FE8003C; Wed, 21 May 2014 18:18:54 +0000 (GMT) Received: from Tereva.local (172.19.41.114) by usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 21 May 2014 14:18:53 -0400 From: Brian Sniffen To: Fabrice In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> <15d5a50ed2244e8595edfa57d7055e2b@BY2PR03MB554.namprd03.prod.outlook.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Wed, 21 May 2014 14:18:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9oQEbx4QO_mn9ts1Xpg_vEIalEM Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 18:19:00 -0000 >>> One challenge is that botnets (that are conduits for most of the >>> spam) also have plenty of spare CPU capacity. >> >> Yes, but each bad node's CPU capacity only outstrips many good node's >> capacities by a little bit---compared to network bandwidth, where >> very often botnets outstrip good nodes' capacity by orders of >> magnitude. Of course the bad nodes will beat out cell phone CPUs; a >> client puzzle scheme has to be about, in some part, "acceptable >> losses." If we can drop new mobile nodes and the botnet, but keep >> service up for (say) established connections and "real" computers, >> that may be okay. > > I don't have hard data at hand, but my guess is that these days TLS > connections from mobile devices far outnumber TLS connections from > "real" computers. So that may not be okay. That doesn't seem to be the case. See . That's not for TLS alone, but Chrome + IE + FF is far greater than Mobile Safari + Android Webkit + all Others. Given that, it would be surprising if Mobile TLS far outnumbered Desktop TLS. And even if so, the number of connections that can get through if you sacrifice some class of connections is still much greater than the number of connections that get through if you let the attacker suppress them all. -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Wed May 21 12:20:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679541A0836 for ; Wed, 21 May 2014 12:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ewam0ILhUhXe for ; Wed, 21 May 2014 12:20:17 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CDC1A0830 for ; Wed, 21 May 2014 12:20:17 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so3243574wib.5 for ; Wed, 21 May 2014 12:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PPXsCnCGv6ejIhudhYyqgcVIGeCiQV6MlYSX8v8GCns=; b=E1WcBxlXxKv1gTNOySaBKydFRp6kmuk9fOgAe8xaBnbe9kpAEfwy3yx/sbb3HFsABF HUcYqC1D8J2IUP1OLYCOhZ90GUtqwycTxXyMS+cWFWi/R4OLxOHumq3QMFYv8ft6WVg8 wNiDzUAGwKDlGpvDkAfj/cW628RiqVG53NAzdrwtTtAyzhhgGh3hYJgL/pEOTUMr97B3 Z2gU3r0p645oUAZGgjS/70u+OGrRlQ+t5xovQoQFvfzI+yraiFcicbtMZEARGAsDGq5a Wgx4kZtl3Rbl+n70Y2L548ylgymGYJ3qlCQ4agkQ2h+QKmk/6nwGX9e0FY8enDsHiAMk 8Sow== X-Received: by 10.180.218.163 with SMTP id ph3mr12081611wic.54.1400700015249; Wed, 21 May 2014 12:20:15 -0700 (PDT) Received: from [192.168.1.100] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id rw4sm23670214wjb.44.2014.05.21.12.20.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 12:20:14 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Wed, 21 May 2014 22:20:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <072720CE-6023-4250-A9D7-68A829C4A2FC@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <859F43324A6FEC448BFEA30C90405FA9037D56@SEAEMBX02.olympus.F5Net.com> <15d5a50ed2244e8595edfa57d7055e2b@BY2PR03MB554.namprd03.prod.outlook.com> To: Brian Sniffen X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i5oSmVdo7Z7q85nGnNpQeu_UwwY Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:20:20 -0000 On May 21, 2014, at 9:18 PM, Brian Sniffen wrote: >>>> One challenge is that botnets (that are conduits for most of the >>>> spam) also have plenty of spare CPU capacity. >>>=20 >>> Yes, but each bad node's CPU capacity only outstrips many good = node's >>> capacities by a little bit---compared to network bandwidth, where >>> very often botnets outstrip good nodes' capacity by orders of >>> magnitude. Of course the bad nodes will beat out cell phone CPUs; a >>> client puzzle scheme has to be about, in some part, "acceptable >>> losses." If we can drop new mobile nodes and the botnet, but keep >>> service up for (say) established connections and "real" computers, >>> that may be okay. >>=20 >> I don't have hard data at hand, but my guess is that these days TLS >> connections from mobile devices far outnumber TLS connections from >> "real" computers. So that may not be okay. >=20 >=20 > That doesn't seem to be the case. See > = . > That's not for TLS alone, but Chrome + IE + FF is far greater than = Mobile > Safari + Android Webkit + all Others. Given that, it would be > surprising if Mobile TLS far outnumbered Desktop TLS. That page you linked allows you to group by device OS, which shows 58.8% = Windows and 8.4% for Mac OS X. There may be some 1% of desktop linux in = those =93Unknown=94 or =93Other=94 categories. So about 2/3 desktop = computers. But this data is for percentage of requests, not connections. I think = mobile sites tend to be simpler and contain less resources than full = sites, Also mobile phones tend to run a lot of little apps that keep = querying servers in the background, much more than desktop computers do, = so it=92s possible that in number of handshakes the score is more even.=20= There=92s also some skew in that an Intel processor running Android is = counted as =93mobile=94 but a tablet running Windows RT is counted as = =93desktop=94, but those are still too rare to alter the results. Yoav From nobody Fri May 23 15:04:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2591A0103 for ; Fri, 23 May 2014 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztkRxgkYHa64 for ; Fri, 23 May 2014 15:03:56 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.142.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7711A00BE for ; Fri, 23 May 2014 15:03:56 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 8C77A73E35ADE; Fri, 23 May 2014 17:03:54 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 63C2073E34F0A for ; Fri, 23 May 2014 17:03:52 -0500 (CDT) Received: from [96.231.225.192] (port=57877 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WnxZ9-0005Xm-Ng for tls@ietf.org; Fri, 23 May 2014 17:03:51 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <7D555152-6398-41DB-85A6-EBE7C9B66CA5@ieca.com> Date: Fri, 23 May 2014 18:03:50 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 96.231.225.192 X-Exim-ID: 1WnxZ9-0005Xm-Ng X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:57877 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cwAFy7ogZqqVpJ4FPnkmyVhkzGQ Subject: [TLS] ipr disclosure: draft-ietf-tls-applayerprotoneg X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 22:03:58 -0000 All, I would like to make the WG aware of a potential IPR issues with = draft-ietf-tls-applayerprotoneg, which is in the RFC editor=92s queue. = On May 12th and 13th, INEOVATION filed IPR disclosures: http://datatracker.ietf.org/ipr/2357/ http://datatracker.ietf.org/ipr/2359/ The IPR concerns are that the "document defines an extension to = negotiate the application layer type in a similar way as described = draft-ietf-tls-applayerprotoneg." Given that this IPR was submitted/disclosed late in the process, I would = like to get a sense of the WG as to whether it is OK to continue with = the publication of the draft as-is. Please respond by May 30th if you = think the WG should not proceed. spt= From nobody Mon May 26 09:34:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9661A01D1 for ; Mon, 26 May 2014 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxgdJLKju8uK for ; Mon, 26 May 2014 09:34:40 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707701A0108 for ; Mon, 26 May 2014 09:34:40 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so12403545qgd.13 for ; Mon, 26 May 2014 09:34:37 -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:content-type; bh=/Nf6ArwYAHN3SAdrThzsmsrPD8SMvFpI8pMrmH6YFd0=; b=ORbpgm0yGlLGAgKMmGXXc5GN5E03Y4hymjfdxBGDMk9QG7LBD+wdOqd70RJupUP1tC goGvCsuw5VGEXvjLFMMbQHBUb00NPVS8LMM51Nz8siav46B7oqXdQKltHFMC7/Rh7Sth FNXXU1WXsViYwWiAQrJzzB8qajFzApDKEkEMyuO9EChF23O6ADmQSAZDH++KTdPyGWBZ 7Yp1dVkTKmkXnlRVZ17MfTjb3Nk3uj+jq8oyAIU2bIWOSjrPuC7HqoKcgXNqQca0MnUk OzoDnqvqdq/wuKMMx5/vHql65B7rJDnQDrRpPIvXM/vu6jaGYA02Ee9oWTdCG0BXjLZb I8MQ== MIME-Version: 1.0 X-Received: by 10.224.223.195 with SMTP id il3mr6312998qab.104.1401122077206; Mon, 26 May 2014 09:34:37 -0700 (PDT) Received: by 10.140.19.229 with HTTP; Mon, 26 May 2014 09:34:37 -0700 (PDT) Date: Mon, 26 May 2014 09:34:37 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LnbKMXqEbjlXzNHAKXhzfoUAi8k Subject: [TLS] Results of interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 16:34:41 -0000 Dear all, It looks like most of the slides were devoted to SNI, and it is not clear what was actually decided. I haven't seen any slides about Triple Handshake, despite being on the interim agenda. Is this a sign that the proposed fix for TLS 1.2 is acceptable? Sincerely, Watson Ladd From nobody Mon May 26 12:40:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DD91A0246 for ; Mon, 26 May 2014 12:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3bW9YXklFET for ; Mon, 26 May 2014 12:40:10 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F35E1A023D for ; Mon, 26 May 2014 12:40:10 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id jt11so8095375pbb.13 for ; Mon, 26 May 2014 12:40:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vxEdCFKCdPoq2JRfAJjHCzbRImpxXOm+UVg3ooKokkw=; b=H9GtKi38alg6XWiZ8gOC/HVNFLEo2Di5+j+E8AlwY+OLM2yqdu5V4RMSp4fesQRO/W aSal6UdTPxNv9wqqaA1Rb2JoPbxK5Js0msS/vFqjJYilj4Alc3JZO5XlJlcuZOdZkTrA /W2bDXYefuzdrJhhM0fbVVaAJYG9cZ43dxAGtusNJ7DuRL+8dOXO8QgpQ2QpA67NeFku kE94TCjMIc1mi7OgCOBweRddlJbTdYkM4K5lnZQxZHevQNtM80dsJjS2Mk7P1qWVjWJb VYm8n31ob+wl9ecUgUHX6b3A4Cq3Nu33DPipM7UYXLzYsYpOUka3WWOwVo5BQXBE/lZ+ EcVg== X-Gm-Message-State: ALoCoQlmq5Zhwo3GVV9Wd3A8vRuDROskHF+fTypWO9A42hVSKVWBROoKbnyWCLfT2q+mmXcYNs4G X-Received: by 10.68.223.202 with SMTP id qw10mr6945335pbc.163.1401133207370; Mon, 26 May 2014 12:40:07 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id iq10sm19589052pbc.14.2014.05.26.12.40.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 12:40:06 -0700 (PDT) From: Andy Lutomirski X-Google-Original-From: Andy Lutomirski Message-ID: <53839895.5000508@mit.edu> Date: Mon, 26 May 2014 12:40:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Watson Ladd , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i1_XakbIFPauG3ooMVVxKyn7TG0 Subject: Re: [TLS] Results of interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 19:40:11 -0000 On 05/26/2014 09:34 AM, Watson Ladd wrote: > Dear all, > > It looks like most of the slides were devoted to SNI, and it is not > clear what was actually decided. > > I haven't seen any slides about Triple Handshake, despite being on the > interim agenda. Is this a sign that the proposed fix for TLS 1.2 is > acceptable? There was a concern that the proposed fix might allow the client to construct two different ClientHellos that would nonetheless result in the same tls-unique value using the pre-TLS-1.2 PRFs. The issue is that, if you could find a SHA-1 collision, then MD5 is short enough that it could be possible to do a length-extension attack and brute-force it to be an MD5 collision as well. No one present knew whether this mattered. --Andy From nobody Mon May 26 13:38:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CF41A0278 for ; Mon, 26 May 2014 13:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8zXsi5OF_Df for ; Mon, 26 May 2014 13:38:11 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB441A0275 for ; Mon, 26 May 2014 13:38:11 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so6716727yha.41 for ; Mon, 26 May 2014 13:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F3TX3EzylQR9NIQwiGUZBz/8qBkcN/zi2yYMSnjvi2U=; b=Xf5WEu+jlsfUhyIauH7ZBwF9EYnBFH3R6U5mOpofnICPaIVyOIG1cKoVfbB4B+26PT Erx/+l/MPsPUhJ3JNVHzjjk1Nk7kSLpBQf76ZzanKZVZgHSV6lkXB7mgisunFIr4fvHW t7hEs5jFKDwKYo0eFLgieDCVvzvXdIhrNWw1iApqaaRvpEPmNCtOuddntPKv+hWQooAg iQdCLQOubF2hpfzi9ZXwnhEKRdvE0hjAMqviDDNnTqSo/pNp8unkUd7ebbSbNyp/bnbG dKtAgBXOnaAZpRf9hoTS0EV5GgHLI5AGFJhzXt2bMmg2RTGqAEAEty4KpzH3rC/hOFPx 1q1A== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr39400100yhh.66.1401136687843; Mon, 26 May 2014 13:38:07 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 26 May 2014 13:38:07 -0700 (PDT) In-Reply-To: <53839895.5000508@mit.edu> References: <53839895.5000508@mit.edu> Date: Mon, 26 May 2014 13:38:07 -0700 Message-ID: From: Watson Ladd To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Bk4imFBoKk99bp53C4kH_x0-h0 Cc: "tls@ietf.org" Subject: Re: [TLS] Results of interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 20:38:13 -0000 On Mon, May 26, 2014 at 12:40 PM, Andy Lutomirski wrote: > On 05/26/2014 09:34 AM, Watson Ladd wrote: >> Dear all, >> >> It looks like most of the slides were devoted to SNI, and it is not >> clear what was actually decided. >> >> I haven't seen any slides about Triple Handshake, despite being on the >> interim agenda. Is this a sign that the proposed fix for TLS 1.2 is >> acceptable? > > There was a concern that the proposed fix might allow the client to > construct two different ClientHellos that would nonetheless result in > the same tls-unique value using the pre-TLS-1.2 PRFs. The issue is > that, if you could find a SHA-1 collision, then MD5 is short enough that > it could be possible to do a length-extension attack and brute-force it > to be an MD5 collision as well. Yes, this is a problem. Basically the session hash needs to be computed with a secure hash, and TLS 1.1 and before don't use secure hashes. I don't think the proposed fix makes this issue worse: from my reading of TLS 1.1 and the tls-unique (should be renamed sometime) the Finished message is computed with the concatenation of a SHA1 and MD5 hash of the messages. How we fix it I don't know yet. > > No one present knew whether this mattered. It seems to me that this would be a problem, and is also a problem for the TLS 1.1 finished message for the same reason. The core issue is this: http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf. In short, with 64 invocations of the hypothetical SHA-1 break, then 2^64 MD5 calculations, you find a collision for the TLS 1.1 finished message. So the composite construction in TLS 1.0 and TLS 1.1 is no more secure than SHA-1. And yes, the dates of TLS 1.1 authorship and the authorship of the paper explaining this flaw are 2006 and 2004 respectively. Sincerely, Watson Ladd > > --Andy -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon May 26 14:41:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937311A029C for ; Mon, 26 May 2014 14:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyMme2WNPxDS for ; Mon, 26 May 2014 14:41:28 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730FE1A0297 for ; Mon, 26 May 2014 14:41:28 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id pa12so9842520veb.32 for ; Mon, 26 May 2014 14:41:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vwJWXpzPS5ANtQlfyd7fMvxgVX6BsiYWF5BslE8K0zE=; b=HohSkkEjlHH4JSoVeJcgU7cx7UOklxS0d6H85IQbXcMnDV/LddWR9FhuPH5Kr/uFVX e3TOsFFZaSOKyZoKgP3tFgbbSm/ctzUqYcYDRV11GmU+2Bh+12ecMs15aoB9e6q71d2p Bvw3fcD7C5tKqPCvg9jX2C7OHXu0YEfpova40K8b5itC7U154lzuauvV7kSqFtVx6H6u UEWzvfj5huUbwc5UOzo2uI4F01XIIDV8wbtMl8vx+Yv5PfZiem50Ek/834RjEjYCFY1X xt6QuIsGiCYZLtaD5yL5xQrNJfrhp2nMZOH27Cv3AToga79SM0e1Kawz4gxFhjDbF/cC Qh7A== X-Gm-Message-State: ALoCoQmH7gwKU5FdOroAiTMtmsa+hQkdQYqWbeSOwqNYXZcWQ4bIxOrzUbdbC2/duw0pZwCYpSXb X-Received: by 10.220.12.66 with SMTP id w2mr23219183vcw.15.1401140484658; Mon, 26 May 2014 14:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.246.39 with HTTP; Mon, 26 May 2014 14:41:04 -0700 (PDT) In-Reply-To: References: <53839895.5000508@mit.edu> From: Andy Lutomirski Date: Mon, 26 May 2014 14:41:04 -0700 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yJnF1x0p5yPLb7xnErZGe53-B-A Cc: "tls@ietf.org" Subject: Re: [TLS] Results of interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 21:41:29 -0000 On Mon, May 26, 2014 at 1:38 PM, Watson Ladd wrote: > On Mon, May 26, 2014 at 12:40 PM, Andy Lutomirski wrote: >> On 05/26/2014 09:34 AM, Watson Ladd wrote: >>> Dear all, >>> >>> It looks like most of the slides were devoted to SNI, and it is not >>> clear what was actually decided. >>> >>> I haven't seen any slides about Triple Handshake, despite being on the >>> interim agenda. Is this a sign that the proposed fix for TLS 1.2 is >>> acceptable? >> >> There was a concern that the proposed fix might allow the client to >> construct two different ClientHellos that would nonetheless result in >> the same tls-unique value using the pre-TLS-1.2 PRFs. The issue is >> that, if you could find a SHA-1 collision, then MD5 is short enough that >> it could be possible to do a length-extension attack and brute-force it >> to be an MD5 collision as well. > > Yes, this is a problem. Basically the session hash needs to be > computed with a secure hash, and TLS 1.1 and before don't use secure > hashes. > I don't think the proposed fix makes this issue worse: from my reading > of TLS 1.1 and the tls-unique (should be renamed sometime) the > Finished message is computed with the concatenation of a SHA1 and MD5 > hash of the messages. > > How we fix it I don't know yet. >> >> No one present knew whether this mattered. > > It seems to me that this would be a problem, and is also a problem for > the TLS 1.1 finished message for the same reason. The core issue is > this: http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf. > > In short, with 64 invocations of the hypothetical SHA-1 break, then > 2^64 MD5 calculations, you find a collision for the TLS 1.1 finished > message. So the composite construction in TLS 1.0 and TLS 1.1 is no > more secure than SHA-1. And yes, the dates of TLS 1.1 authorship and > the authorship of the paper explaining this flaw are 2006 and 2004 > respectively. My possibly silly suggestion was to replace H(client hello || server hello) with H(server random || client hello || server hello). This may make attacks on this considerably harder to mount. --Andy From nobody Mon May 26 14:50:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40991A02AA for ; Mon, 26 May 2014 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo0fNBm6-J46 for ; Mon, 26 May 2014 14:50:32 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663461A02A1 for ; Mon, 26 May 2014 14:50:32 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so663993wib.4 for ; Mon, 26 May 2014 14:50:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=l3Xcgxzijfmm5dKG1RvpTTYFu7t7+b1Q9OMJn5HzSnI=; b=cqzzvhn2ZpDtiwFwNj59q8NTFHNTTrruaL7CsBhGOoT0/1an5PyjU+e+a7t0dufY9s D9EPEyHFv8MaHSK1gSsEZ3OagANo4by5EgyUNgiFuue/03qFjucBRlDEOTPGidLo4i5H A7ujjkh3JV3TSOt4iKjy3VTgVeAfVX4ncscyt72tWux2yXnjn8O+4CKd6iqz4Aj7ihtG nx7SOHq/QfTOi79mrO6an4D256nWhpOi3LyVlM0P21i7P38E/md2Y7MTvWPWh4waCerx oTxeNaGoLAGeCpDII5+it/PZH7iDYLqoB+GiUwVDyMz4KBs55qbcd+caUdkX6vM65Lc/ 8gEw== X-Gm-Message-State: ALoCoQlGlXFAToFy5mdjRKOwUEc2pDyoT+PuNjZb2MVOX5KThYryYivv6E8k7HTNsGqTyrw4rjV4 X-Received: by 10.194.62.176 with SMTP id z16mr32482960wjr.76.1401141027333; Mon, 26 May 2014 14:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 26 May 2014 14:49:47 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <53839895.5000508@mit.edu> From: Eric Rescorla Date: Mon, 26 May 2014 14:49:47 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7ba979c237037304fa549188 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TC3o2L7DHgGsQ-UfzkWNBsoTvFM Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Results of interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 21:50:34 -0000 --047d7ba979c237037304fa549188 Content-Type: text/plain; charset=UTF-8 On Mon, May 26, 2014 at 1:38 PM, Watson Ladd wrote: > On Mon, May 26, 2014 at 12:40 PM, Andy Lutomirski > wrote: > > On 05/26/2014 09:34 AM, Watson Ladd wrote: > >> Dear all, > >> > >> It looks like most of the slides were devoted to SNI, and it is not > >> clear what was actually decided. > >> > >> I haven't seen any slides about Triple Handshake, despite being on the > >> interim agenda. Is this a sign that the proposed fix for TLS 1.2 is > >> acceptable? > > > > There was a concern that the proposed fix might allow the client to > > construct two different ClientHellos that would nonetheless result in > > the same tls-unique value using the pre-TLS-1.2 PRFs. The issue is > > that, if you could find a SHA-1 collision, then MD5 is short enough that > > it could be possible to do a length-extension attack and brute-force it > > to be an MD5 collision as well. > > Yes, this is a problem. Basically the session hash needs to be > computed with a secure hash, and TLS 1.1 and before don't use secure > hashes. > I don't think the proposed fix makes this issue worse: from my reading > of TLS 1.1 and the tls-unique (should be renamed sometime) the > Finished message is computed with the concatenation of a SHA1 and MD5 > hash of the messages. > To clarify, I believe the concern here was not directly about the Finished messages (though they are perhaps implicated as well) but about the key computation. Specifically, in current TLS, the MS [0] and subsequently the session keys [1] are computed as a PRF of the PMS/MS and random values, specifically: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; As the triple handshake paper observes, this allows an attacker to force two handshakes to produce the same MS by duplicating the PMS and the randoms. The current proposal is to replace the random values with a hash of the handshake transcript, i.e., master_secret = PRF(pre_master_secret, "extended master secret", session_hash) [0..47]; However if there is a collision in the function used to compute the session hash, then this might allow an attacker to produce a session_hash collision which might potentially reenable the attack (and note that the attacker can potentially inject a lot of data here through extensions). -Ekr [0] http://tools.ietf.org/html/rfc4346#section-8.1 [1] http://tools.ietf.org/html/rfc4346#section-6.3 How we fix it I don't know yet. > > > > No one present knew whether this mattered. > > It seems to me that this would be a problem, and is also a problem for > the TLS 1.1 finished message for the same reason. The core issue is > this: http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf. > > In short, with 64 invocations of the hypothetical SHA-1 break, then > 2^64 MD5 calculations, you find a collision for the TLS 1.1 finished > message. So the composite construction in TLS 1.0 and TLS 1.1 is no > more secure than SHA-1. And yes, the dates of TLS 1.1 authorship and > the authorship of the paper explaining this flaw are 2006 and 2004 > respectively. > > Sincerely, > Watson Ladd > > > > --Andy > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7ba979c237037304fa549188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 26, 2014 at 1:38 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Mon, May 26, 2014 at 12:40 PM, Andy Lutomirski <= ;luto@amacapital.n= et> wrote:
> On 05/26/2014 09:34 AM, Watson Ladd wrote:
>> Dear all,
>>
>> It looks like most of the slides were devoted to SNI, and it is no= t
>> clear what was actually decided.
>>
>> I haven't seen any slides about Triple Handshake, despite bein= g on the
>> interim agenda. Is this a sign that the proposed fix for TLS 1.2 i= s
>> acceptable?
>
> There was a concern that the proposed fix might allow the client to > construct two different ClientHellos that would nonetheless result in<= br> > the same tls-unique value using the pre-TLS-1.2 PRFs. =C2=A0The issue = is
> that, if you could find a SHA-1 collision, then MD5 is short enough th= at
> it could be possible to do a length-extension attack and brute-force i= t
> to be an MD5 collision as well.

Yes, this is a problem. Basically the session hash needs to be
computed with a secure hash, and TLS 1.1 and before don't use secure hashes.
I don't think the proposed fix makes this issue worse: from my reading<= br> of TLS 1.1 and the tls-unique (should be renamed sometime) the
Finished message is computed with the concatenation of a SHA1 and MD5
hash of the messages.

To clarify, I bel= ieve the concern here was not directly about
the Finished message= s (though they are perhaps implicated
as well) but about the key = computation.

Specifically, in current TLS, the MS [0] and subsequent= ly the
session keys [1] are computed as a PRF of the PMS/MS and
random values, specifically:


  master_secret =3D PRF(pre_mas=
ter_secret, "master secret",
                           ClientHello.random + ServerHello.random)
       [0..47];

As the triple handshake paper observ= es, this allows an attacker
to force two handshakes to produce th= e same MS by duplicating
the PMS and the randoms. The current pro= posal is to replace the
random values with a hash of the handshake transcript, i.e.,

 master_secret =
=3D PRF(pre_master_secret, "extended master secret",
                       session_hash)
                       [0..47];
However if there is a collision in the function used to co= mpute the
session hash, then this might allow an attacker to prod= uce a
session_hash collision which might potentially reenable the= attack
(and note that the attacker can potentially inject a lot of data here<= /div>
through extensions).

-Ekr

=

<= div>





How we fix it I don't know yet.
>
> No one present knew whether this mattered.

It seems to me that this would be a problem, and is also a problem fo= r
the TLS 1.1 finished message for the same reason. The core issue is
this: http://www.iacr.org/cryptodb/archive/2004/CRYPTO/14= 72/1472.pdf.

In short, with 64 invocations of the hypothetical SHA-1 break, then
2^64 MD5 calculations, you find a collision for the TLS 1.1 finished
message. So the composite construction in TLS 1.0 and TLS 1.1 is no
more secure than SHA-1. And yes, the dates of TLS 1.1 authorship and
the authorship of the paper explaining this flaw are 2006 and 2004
respectively.

Sincerely,
Watson Ladd
>
> --Andy



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither =C2=A0Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--047d7ba979c237037304fa549188-- From nobody Mon May 26 18:53:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43B1A02EC for ; Mon, 26 May 2014 18:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSYssIaVqhF6 for ; Mon, 26 May 2014 18:53:48 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD06E1A02E5 for ; Mon, 26 May 2014 18:53:48 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id rd3so8312843pab.35 for ; Mon, 26 May 2014 18:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=+mvHTuOGgXHHxRD0l5IvnxbvukCI863CKjwn03oPAL0=; b=P3bPrzP8b5e5kaRDyVxRsQXytrgML1ztpjuzZ9b8OlDoTtAf+AKPcEopa4omhV1eOL sAMNa7h0qKmE88CBtxB1yd63IEnb0kRztjz1QOYttQsthpD5/ETQfNfoeA+NTSWOzAoU HCoTHShJZOMj0mAaGAGrVLPHj+Nm6Qsp0E7ovE8MD0wGcw+1rmuci1rqyFdhQWGEOfqj fACBKGYcRS30m3Iw+q+cY4m0d2pJ1g8wYIXVI8IzYplE7w5wC52W1Okl/c/JT7aQp44P loOGsJKrWY9YeFvVZly6T8WKXiRspwAiNhGxEmBMeJG+6uS5gSQLhJkS3MCv9mf7Xth1 po2Q== X-Gm-Message-State: ALoCoQnXsR5YiLWSeFIHZm2Sdomdc0ZYC+3hVLubV9VeR06rSiMWwFFA798YIyEcE3lHvhIHjctx X-Received: by 10.66.162.103 with SMTP id xz7mr28072932pab.104.1401155625660; Mon, 26 May 2014 18:53:45 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id op3sm20376251pbc.40.2014.05.26.18.53.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 18:53:44 -0700 (PDT) Message-ID: <5383F02F.4050706@nthpermutation.com> Date: Mon, 26 May 2014 21:53:51 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c2916PBttbx5BI_-EG2dMTMQ20U Subject: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 01:53:51 -0000 I went back and read the minutes of the London meeting about removing static RSA and wanted to clarify what that really meant. The minutes had EKR mentioning this in conjunction with DH which seems different that what I kept hearing at the interim meeting. Could someone confirm "removing static RSA" results in removing the use of RSA as a key transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of TLS1.2 - basically removing this section and prohibiting "rsa" and "rsa_psk" as key exchange algorithms)? To go further and take this up from specific cryptography - will/should TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key Agreement mechanisms for key exchange? Also in the London meeting it was agreed limit ciphertext to AEAD style processing - e.g. in the TLSCipherText record to remove "stream" and "block" as valid choices. Does that result in the removal of sections 6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3? Does it also result in changing the output of the "key expansion" phase as only "client_write_key" and "server_write_key"s will be needed for AEAD? Is there any desire to specify a AEAD general block cipher mode/mac construct with an integral key expansion function? E.g. could something like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt be adapted to be a general model for TLS or is this out of scope for the TLS1.3 main document? Mike From nobody Mon May 26 19:33:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E424B1A0307 for ; Mon, 26 May 2014 19:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-W-xMH4512W for ; Mon, 26 May 2014 19:33:05 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5341A02F4 for ; Mon, 26 May 2014 19:33:04 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so8793603wgh.20 for ; Mon, 26 May 2014 19:33:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6IyZZLktgydOvXgrr1qGTs0fz4lUBIqiDkKqDl/6imM=; b=BYyC1m2bWWeb9763usBqk7zxXwjiQjEOyVK2nDPFlkZ+qqFVQhvyV5kfFzoR5HUHe/ RNVELsaQezHsbG5V9yLWcus6Pd6ZWxg3ECY1g1YhMGRWtFQ0XkVUu78f909jHZ1DXjT8 HTKK5E/kPs4TsTcAX1YIueBA6GtJ4KN5yHL+PsAUXkK2CPDLOPMUBqIXdfIU+JIDObcm pNNZHG46YqYPdNo4I0sf0dOkoWH2A3g6xlFaDhgsWQ7bfN0qRiia9ruUapJ9NZ8L02S3 jh49Aoyuir/P7k/1VPyKF+CSzDQ3ZfF0t0uk2iKSEbNs0oD0p3uaDiR1bQdsbGeX1P96 nJ3g== X-Gm-Message-State: ALoCoQm6jRUmrw+1bxSIOhTsg4MZqf5iek6RuRRuwn4PaLAV5nDFGbTEdi1gizFhKT75tRkRklBy X-Received: by 10.180.93.234 with SMTP id cx10mr17881037wib.18.1401157980980; Mon, 26 May 2014 19:33:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 26 May 2014 19:32:20 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <5383F02F.4050706@nthpermutation.com> References: <5383F02F.4050706@nthpermutation.com> From: Eric Rescorla Date: Mon, 26 May 2014 19:32:20 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d04388e17bb251b04fa5883e6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nXmQ1OmpCdA50UwUmMrnyCE0bL8 Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:33:07 -0000 --f46d04388e17bb251b04fa5883e6 Content-Type: text/plain; charset=UTF-8 On Mon, May 26, 2014 at 6:53 PM, Michael StJohns wrote: > I went back and read the minutes of the London meeting about removing > static RSA and wanted to clarify what that really meant. The minutes had > EKR mentioning this in conjunction with DH which seems different that what > I kept hearing at the interim meeting. Could someone confirm "removing > static RSA" results in removing the use of RSA as a key transport > mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of TLS1.2 - > basically removing this section and prohibiting "rsa" and "rsa_psk" as key > exchange algorithms)? > Yes. This has already been merged into github: https://github.com/tlswg/tls13-spec/commit/45aed081b1e3790507d91e3e6cc48451ed9beb94 To go further and take this up from specific cryptography - will/should TLS > 1.3 prohibit *any* Key Transport mechanism and retain only Key Agreement > mechanisms for key exchange? > I don't believe there has been any consensus on this topic. It certainly would be easy to do if that's what the WG wants. > > Also in the London meeting it was agreed limit ciphertext to AEAD style > processing - e.g. in the TLSCipherText record to remove "stream" and > "block" as valid choices. Does that result in the removal of sections > 6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3? Yes. I'm working on a pull request for this now. > Does it also result in changing the output of the "key expansion" phase as > only "client_write_key" and "server_write_key"s will be needed for AEAD? > I don't believe so, since AEAD still at least potentially requires an IV. Is there any desire to specify a AEAD general block cipher mode/mac > construct with an integral key expansion function? E.g. could something > like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt be > adapted to be a general model for TLS or is this out of scope for the > TLS1.3 main document? Certainly this is something one could in principle do. However I know that there are some who would prefer to not specify any CBC cipher suite so I expect they may want to weigh in now. Another alternative would be to specific an AES-CTR/HMAC combined mode. -Ekr --f46d04388e17bb251b04fa5883e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, May 26, 2014 at 6:53 PM, Michael StJohns <msj@nthpermutation.com= > wrote:
I went back and read the minutes of the London meeting abo= ut removing static RSA and wanted to clarify what that really meant. The mi= nutes had EKR mentioning this in conjunction with DH which seems different = that what I kept hearing at the interim meeting. Could someone confirm &quo= t;removing static RSA" results in removing the use of =C2=A0RSA as a k= ey transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of TLS1= .2 - basically removing this section and prohibiting "rsa" and &q= uot;rsa_psk" =C2=A0as key exchange algorithms)?

Yes. This has already been merged into git= hub:


To go further and take this up from specific cryptography - will/should TLS= 1.3 prohibit *any* Key Transport mechanism and retain only Key Agreement m= echanisms for key exchange?

I don't= believe there has been any consensus on this topic. It certainly would
be easy to do if that's what the WG wants.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Also in the London meeting it was agreed limit ciphertext to AEAD style pro= cessing - e.g. in the TLSCipherText record to remove "stream" and= "block" as valid choices. =C2=A0Does that result in the removal = of sections 6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3?

Yes. I'm working on a pull request for this now.

=C2=A0
Does it also result in changing the output of the "key expansion"= ; phase as only "client_write_key" and "server_write_key&quo= t;s will be needed for AEAD?

I don'= t believe so, since AEAD still at least potentially requires an IV.


Is there any desire to specify a AEAD general block cipher mode/mac constru= ct with an integral key expansion function? =C2=A0E.g. could something like= http://www.ietf.org/id/draft-mcgrew-aead-aes-c= bc-hmac-sha2-04.txt be adapted to be a general model for TLS or is this= out of scope for the TLS1.3 main document?

Certainly this is something one could in principle do. = However I know that
there are some who would prefer to not specif= y any CBC cipher suite so
I expect they may want to weigh in now.= Another alternative would be to
specific an AES-CTR/HMAC combined mode.

-Ekr<= /div>


--f46d04388e17bb251b04fa5883e6-- From nobody Mon May 26 20:14:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE121A0337 for ; Mon, 26 May 2014 20:14:31 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvVMqoaLW2nV for ; Mon, 26 May 2014 20:14:29 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DF41A032D for ; Mon, 26 May 2014 20:14:29 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id rr13so8498659pbb.35 for ; Mon, 26 May 2014 20:14:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=RyfrYO4OJ/xA3QCsnTlJPuaxwsmHcZYzpOl+os8sUlk=; b=VPvz0i4CGES0xZcJnO7r9FyEdVkIt8gRMLiiu0ciXuHNGe04fg0K+YavyZUFuYiv8H Op1H/UupBXgywSJZHy0Aj9Sv4aSCRMOzAyBbU+dvskEA4w1IALYlmI82adbo0AcxK5jT OWbySygaJj+Aqev8qAx6yHVVGgPq8xWNd0pEzNYeBnclstUqPiBeHvjp6qbAy5bsAW98 tj3y7KVj9e+nxuqyM1B0ceBUHRJGgGmK4EWu1P5qNpMZCla5OHSXmWff3CvqmRfR0Wuv NcCf6b6snOO2wgB3rwC/7wvDPdlBPFV8d5F3pBzz+MrhlaSy/Kpu9vG7qUIemB25bY5u 06/w== X-Gm-Message-State: ALoCoQmjf7d6EBiGsDFJuPjhxkiMT8SFMdWDomJTSPg8U/K40iY3jiqZLg0c67+vrXt76t9GmyGi X-Received: by 10.66.137.109 with SMTP id qh13mr32661276pab.39.1401160466845; Mon, 26 May 2014 20:14:26 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id ec2sm20575890pbc.63.2014.05.26.20.14.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 20:14:26 -0700 (PDT) Message-ID: <53840318.10902@nthpermutation.com> Date: Mon, 26 May 2014 23:14:32 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eric Rescorla References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040203020802000507070900" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zoY1O1VMsT-ZfK6DvCJh6x1cnOc Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:14:31 -0000 This is a multi-part message in MIME format. --------------040203020802000507070900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/26/2014 10:32 PM, Eric Rescorla wrote: > > Does it also result in changing the output of the "key expansion" > phase as only "client_write_key" and "server_write_key"s will be > needed for AEAD? > > > I don't believe so, since AEAD still at least potentially requires an IV. Right - but we really need to get IV material in a way where it isn't derived from the master secret. What I meant was that "client_write_mac_key" and "server_write_mac_key" are no longer generated since they aren't necessary for AEAD - correct? > > > Is there any desire to specify a AEAD general block cipher > mode/mac construct with an integral key expansion function? E.g. > could something like > http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt > be adapted to be a general model for TLS or is this out of scope > for the TLS1.3 main document? > > > Certainly this is something one could in principle do. However I know that > there are some who would prefer to not specify any CBC cipher suite so > I expect they may want to weigh in now. Another alternative would be to > specific an AES-CTR/HMAC combined mode. There's things that the TLS base document should be specifying (e.g. we'll only do AEAD style modes and here's the interface), and then there's getting into the nitty-gritty of specific cipher suites. I'm wondering if it would make sense to completely remove all of the cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to a separate document and have the base document only talk about the cryptographic constructs, message formats, negotiation schemes etc? That makes support of the base specification a bit more independent from the crypto suite specifications. With respect to the use of compound AEAD functions - I think you have to allow for things like McGrew's draft, as well as the equivalent on non-AES, non-NIST regional mechanisms to be specified as a compound AEAD. CBC has gotten bad press, but it's out there, it's built in to a lot of hardware and, used with a good integrity mechanism (in encrypt-then-mac order), seems to be "secure enough" for the given uses. --------------040203020802000507070900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/26/2014 10:32 PM, Eric Rescorla wrote:
Does it also result in changing the output of the "key expansion" phase as only "client_write_key" and "server_write_key"s will be needed for AEAD?

I don't believe so, since AEAD still at least potentially requires an IV.

Right - but we really need to get IV material in a way where it isn't derived from the master secret.    What I meant was that "client_write_mac_key" and "server_write_mac_key" are no longer generated since they aren't necessary for AEAD - correct?



Is there any desire to specify a AEAD general block cipher mode/mac construct with an integral key expansion function?  E.g. could something like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt be adapted to be a general model for TLS or is this out of scope for the TLS1.3 main document?

Certainly this is something one could in principle do. However I know that
there are some who would prefer to not specify any CBC cipher suite so
I expect they may want to weigh in now. Another alternative would be to
specific an AES-CTR/HMAC combined mode.

There's things that the TLS base document should be specifying (e.g. we'll only do AEAD style modes and here's the interface), and then there's getting into the nitty-gritty of specific cipher suites.

 I'm wondering if it would make sense to completely remove all of the cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to a separate document and have the base document only talk about the cryptographic constructs, message formats, negotiation schemes etc?  That makes support of the base specification a bit more independent from the crypto suite specifications.

With respect to the use of compound AEAD functions - I think you have to allow for things like McGrew's draft, as well as the equivalent on non-AES, non-NIST regional mechanisms to be specified as a compound AEAD.  CBC has gotten bad press, but it's out there, it's built in to a lot of hardware and, used with a good integrity mechanism (in encrypt-then-mac order), seems to be "secure enough" for the given uses.


--------------040203020802000507070900-- From nobody Mon May 26 20:26:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05C1A0347 for ; Mon, 26 May 2014 20:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqbc__ArQXT5 for ; Mon, 26 May 2014 20:26:22 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405B11A01C8 for ; Mon, 26 May 2014 20:26:22 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so8708805wgg.21 for ; Mon, 26 May 2014 20:26:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M8hyR88vOZWyy3Xbh1H0cx/OIBui5SH6qYTNLXurmX0=; b=fX5UQ2dXK80ZP53sn4c3PEzlThYL8Cuky5KBPSPtO0WrYtH57w1MmAYAfLbig3X70d p7qUTTYgwegrygXJI7uYCv+nx77bezFtZ8R4weWo4fTui+VWJYhjjd4/62KR7RhqhwKX 373Tg/xnAAPLNQ6TCWwRR4Um8uqhtS+zBg1exna97gPv5XBWXklvsKlBDFi3l25pMnKW 7t+tj7iXfGVsREfCR6SPzuNpkQrmpUpi7HlWsmmsVVRMAAqZBHr/HBQ6NhmUzN+SUFmJ eN7Dsmuf0h2BtDPtF4G2P1WRcFTUcQQKJHUOxBoEDTzO68C1wZIyYB5zAt4xqFQcAbuS tkAQ== X-Gm-Message-State: ALoCoQnUubpf+hbXJwZiWcE9SYml6LORdSeS6AFnv0Q6dcXtiqNVTag03POJN/t2UCzpzJYRXp6T X-Received: by 10.180.94.98 with SMTP id db2mr33564904wib.1.1401161178120; Mon, 26 May 2014 20:26:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 26 May 2014 20:25:38 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53840318.10902@nthpermutation.com> References: <5383F02F.4050706@nthpermutation.com> <53840318.10902@nthpermutation.com> From: Eric Rescorla Date: Mon, 26 May 2014 20:25:38 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d044271404b9e4d04fa5942ee Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0UlDJGB5AARXTfHu-lPzoRr7LXU Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:26:24 -0000 --f46d044271404b9e4d04fa5942ee Content-Type: text/plain; charset=UTF-8 On Mon, May 26, 2014 at 8:14 PM, Michael StJohns wrote: > On 5/26/2014 10:32 PM, Eric Rescorla wrote: > > Does it also result in changing the output of the "key expansion" phase >> as only "client_write_key" and "server_write_key"s will be needed for AEAD? >> > > I don't believe so, since AEAD still at least potentially requires an IV. > > > Right - but we really need to get IV material in a way where it isn't > derived from the master secret. > I don't agree with this claim. As I understand the constraints, they merely need to be derived in a way that is isolated from the keying material. Is there a reason that it's unsafe to generate the IVs from the MS provided that this condition is met? > What I meant was that "client_write_mac_key" and "server_write_mac_key" > are no longer generated since they aren't necessary for AEAD - correct? > Yes, I agree with this. Is there any desire to specify a AEAD general block cipher mode/mac >> construct with an integral key expansion function? E.g. could something >> like http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txtbe adapted to be a general model for TLS or is this out of scope for the >> TLS1.3 main document? > > > Certainly this is something one could in principle do. However I know > that > there are some who would prefer to not specify any CBC cipher suite so > I expect they may want to weigh in now. Another alternative would be to > specific an AES-CTR/HMAC combined mode. > > > There's things that the TLS base document should be specifying (e.g. we'll > only do AEAD style modes and here's the interface), and then there's > getting into the nitty-gritty of specific cipher suites. > Well, ultimately whether it's in the base document or not, the TLS WG will need to decide whether to specify a cipher suite that uses any particular set of algorithms. > I'm wondering if it would make sense to completely remove all of the > cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to a > separate document and have the base document only talk about the > cryptographic constructs, message formats, negotiation schemes etc? > IMO this would not promote understanding. With respect to the use of compound AEAD functions - I think you have to > allow for things like McGrew's draft, as well as the equivalent on non-AES, > non-NIST regional mechanisms to be specified as a compound AEAD. CBC has > gotten bad press, but it's out there, it's built in to a lot of hardware > and, used with a good integrity mechanism (in encrypt-then-mac order), > seems to be "secure enough" for the given uses. > I'm not sure what "allow for" means. There's no technical reason that such a cipher suite cannot be specified for TLS, within the existing AEAD framework, but that does not mean that the WG will be in favor of specifying such a suite. As I said, there are people who would prefer not to have CBC at all. -Ekr --f46d044271404b9e4d04fa5942ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 26, 2014 at 8:14 PM, Michael StJohns = <msj@nthperm= utation.com> wrote:
=20 =20 =20
On 5/26/2014 10:32 PM, Eric Rescorla wrote:
Does it also result in changing the output of the "key expansion" phase as only "client_write_key" and "server_write_key"s will be needed for AEAD?

I don't believe so, since AEAD still at least potentially requires an IV.

Right - but we really need to get IV material in a way where it isn't derived from the master secret.=C2=A0=C2=A0

I don't agree with this claim. As I understand the= constraints, they merely
need to be derived in a way that is iso= lated from the keying material.
Is there a reason that it's unsafe to generate the IVs from the MS= provided
that this condition is met?

= =C2=A0
=C2=A0 What I meant was that "client_write_mac_key" and "server_write_mac_key" a= re no longer generated since they aren't necessary for AEAD - correct?

Yes, I agree with this.

Is there any desire to specify a AEAD general block cipher mode/mac construct with an integral key expansion function? =C2=A0E.g. could something like http://www.ietf.org/id/draft-mc= grew-aead-aes-cbc-hmac-sha2-04.txt be adapted to be a general model for TLS or is this out of scope for the TLS1.3 main document?

Certainly this is something one could in principle do. However I know that
there are some who would prefer to not specify any CBC cipher suite so
I expect they may want to weigh in now. Another alternative would be to
specific an AES-CTR/HMAC combined mode.

There's things that the TLS base document should be specifying (e.g= . we'll only do AEAD style modes and here's the interface), and t= hen there's getting into the nitty-gritty of specific cipher suites.

Well, ultimately whether it's = in the base document or not, the TLS WG will need
to decide wheth= er to specify a cipher suite that uses any particular set of
algorithms.

=C2=A0
=C2=A0I'm wondering if it would make sense to completely remove all= of the cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to a separate document and have the base document only talk about the cryptographic constructs, message formats, negotiation schemes etc?=C2=A0

IMO this would= not promote understanding.


With respect to the use of compound AEAD functions - I think you have to allow for things like McGrew's draft, as well as the equivalent on non-AES, non-NIST regional mechanisms to be specified as a compound AEAD. CBC has gotten bad press, but it's out there, it's built in to a lot of hardware and, used with a good integrity mechanism (in encrypt-then-mac order), seems to be "secure enough&= quot; for the given uses.

I'm not s= ure what "allow for" means.

There's = no technical reason that such a cipher suite cannot be specified for TLS,= =C2=A0
within the existing AEAD framework, but that does not mean that the WG= will be
in favor of specifying such a suite. As I said, there ar= e people who would prefer
not to have CBC at all.

-Ekr

--f46d044271404b9e4d04fa5942ee-- From nobody Tue May 27 06:39:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB29D1A0137 for ; Tue, 27 May 2014 06:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7DnUx_qyk2x for ; Tue, 27 May 2014 06:39:48 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8365D1A0143 for ; Tue, 27 May 2014 06:39:48 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RDdiMt008062; Tue, 27 May 2014 09:39:44 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Eric Rescorla , Michael StJohns Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPeVP+xhSBxDY3A06EGaypXGdrtptUA/QAgAADGgCAAGhfgA== Date: Tue, 27 May 2014 13:39:20 +0000 Message-ID: References: <5383F02F.4050706@nthpermutation.com> <53840318.10902@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484028351_85881" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-27_02:2014-05-26,2014-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270190 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HMaAGUgi58OYRCE7PzX5Rb60Jr8 Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:39:54 -0000 --B_3484028351_85881 Content-type: multipart/alternative; boundary="B_3484028351_33429" --B_3484028351_33429 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit >>>> Does it also result in changing the output of the "key expansion" phase as >>>> only "client_write_key" and "server_write_key"s will be needed for AEAD? >>> >>> I don't believe so, since AEAD still at least potentially requires an IV. >> >> Right - but we really need to get IV material in a way where it isn't derived >> from the master secret. s/isn't derived/is cryptographically separated/ And everything will be fine. ;) > I don't agree with this claim. As I understand the constraints, they merely > need to be derived in a way that is isolated from the keying material. Yes. > Is there a reason that it's unsafe to generate the IVs from the MS provided > that this condition is met? IMHO, no. :-) --B_3484028351_33429 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable <= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
Doe= s it also result in changing the output of the "key expansion" phase as only= "client_write_key" and "server_write_key"s will be needed for AEAD?

I don't believe so, since AEAD still at least p= otentially requires an IV.

Right - but we really need to get IV material in a way where it isn't deriv= ed from the master secret.  
<= /div>

s/isn't derived/is crypto= graphically separated/

And everything will be fine.= ;) 

I don't agree with this claim. As I understand th= e constraints, they merely
need to be derived in a way that is iso= lated from the keying material.
<= div>
Yes.

=
Is there a reason that it's unsafe = to generate the IVs from the MS provided
that this condition is me= t?

IMHO, no. = :-)
--B_3484028351_33429-- --B_3484028351_85881 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCB6jSYPF85qxp9+TXYWJKF7P51J3WxNRI6ExTR9O9BwRDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxMzM5MTFaMA0GCSqGSIb3 DQEBAQUABIIBAKp7I8xYq8pToNvD2Pnc1ji7KX9DGx4lDPmiXjqEz0o/TTD3xw/R0zWUlp/O IW29lkMbIr1CbInt9KH9AFwHPLYbya2D1lDqXuX5gg0qGebc0MrTDziHOtEEX1powvETDEUT ykEcrtyUXRfiejjpwMAyPRlbiKWviBaBS85zLhssZTklE6NEV1Vv3Hwxa3F+IvEiqfd2RwVl lfOgPAskFvY74J9d07cSLn8VD5pmKyYhi2ndlWVOmKAM2hChzO0tdpK7vMtHWb4Hq0Dix7z1 Zj33N6YK4uw5aPOtBxvyWVmWUok14V9rOPrI/aW6PUQgUzE3JnQfrYvFekFlVG8fL8A= --B_3484028351_85881-- From nobody Tue May 27 06:44:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2721A011D for ; Tue, 27 May 2014 06:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwzB1H6S8l-X for ; Tue, 27 May 2014 06:44:00 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id DB17D1A0148 for ; Tue, 27 May 2014 06:43:59 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RDhZei012440 for ; Tue, 27 May 2014 09:43:56 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPeU6KeYqPYRGIwU23P/t1hsTaIptUcKUA Date: Tue, 27 May 2014 13:43:31 +0000 Message-ID: References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: <5383F02F.4050706@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484028604_102503" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-27_02:2014-05-26,2014-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270193 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oqlpnX5IUMy392TSH7XUNfqQnqE Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:44:02 -0000 --B_3484028604_102503 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit >...... Could someone confirm >"removing static RSA" results in removing the use of RSA as a key >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of >TLS1.2 - basically removing this section and prohibiting "rsa" and >"rsa_psk" as key exchange algorithms)? > >To go further and take this up from specific cryptography - will/should >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key >Agreement mechanisms for key exchange? What would be the consequences of this decision for embedded servers that may not have a good source of randomness to meaningfully engage in [EC]DH[E]? --B_3484028604_102503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCD8TGgywkcUzFqpqg5Rk+Dlf9w7B9t/PJIn8gEgOMjGHDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxMzQzMjRaMA0GCSqGSIb3 DQEBAQUABIIBAHUlRv9rqBqXFFmNL8mR950C2LOiW3/ct45tUNJy7KHa9R/KV+nBmpU/B6m9 I6UrpjgQPDjI+FkAes5pikvOkv+h+TfYf+qzv1tqwytqjHSN/3EYj/l9o5iDxPKOXz+bIy5Q W5xTMPPuEnQuW8LYXkva91Fvtko1Eg92A11F/s8yloFc4bBOJZPcl6MTJKt7SeecJId428cu tppKInaN1SVaSQ2J+lqCPFLp8giINJ/wA56MeyTnfFk/lalEhwa22lwp91XGRrc3eB7j/4+G R3/nsHg8rLd+AXvJUdlupsfIOUfEuMB1CwVsRSLcFoHGgZQcIfgj46Co5KbLDMLaN7U= --B_3484028604_102503-- From nobody Tue May 27 06:48:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04881A0153 for ; Tue, 27 May 2014 06:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3BR2bhAy8XI for ; Tue, 27 May 2014 06:48:45 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 24FFE1A0137 for ; Tue, 27 May 2014 06:48:44 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RDmRKP017691 for ; Tue, 27 May 2014 09:48:41 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Results of interim meeting Thread-Index: AQHPeQBlyWKsiTpCKEixNr5jRMe1MZtThaOAgAAQN4CAABQGgIAAyLkA Date: Tue, 27 May 2014 13:48:21 +0000 Message-ID: References: <53839895.5000508@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484028892_75811" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-27_02:2014-05-26,2014-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270193 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mnpEEX_gE_tDvZv2zarUfflMT9A Subject: Re: [TLS] Results of interim meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:48:49 -0000 --B_3484028892_75811 Content-type: multipart/alternative; boundary="B_3484028892_120287" --B_3484028892_120287 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit > Specifically, in current TLS, the MS [0] and subsequently the > session keys [1] are computed as a PRF of the PMS/MS and > random values, specifically: > > master_secret = PRF(pre_master_secret, "master secret", > ClientHello.random + ServerHello.random) > [0..47]; > > As the triple handshake paper observes, this allows an attacker > to force two handshakes to produce the same MS by duplicating > the PMS and the randoms. The current proposal is to replace the > random values with a hash of the handshake transcript, i.e., > > master_secret = PRF(pre_master_secret, "extended master secret", > session_hash) > [0..47]; Why not master_secret = PRF(pre_master_secret, "extended master secret", Hash(ClientHello.random + ServerHello.random + session_hash)) [0..47]; --B_3484028892_120287 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Specifically, in current TL= S, the MS [0] and subsequently the
session keys [1] are computed a= s a PRF of the PMS/MS and
random values, specifically:
<= br>
  master_sec=
ret =3D PRF(pre_master_secret, "master secret",
                           ClientHello.random + ServerHello.random)
       [0..47];

As the triple handshake paper observ= es, this allows an attacker
to force two handshakes to produce the= same MS by duplicating
the PMS and the randoms. The current propo= sal is to replace the
random values with a hash of the handshake t= ranscript, i.e.,

 master_secret =3D PRF(pre_master_secret, "extended master secret",
                       session_hash)
                       [0..47];
Why not 

master_secret =3D PRF(pre_master_secret, "exten= ded master secret",
               =
           Hash(ClientHello.random + ServerHello.rand=
om + session_hash)) [0..47];
<= /html> --B_3484028892_120287-- --B_3484028892_75811 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCBj05/sPvaxidmqn0Xojp1kS5498BzT0laMYdM6KU0dlzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxMzQ4MTJaMA0GCSqGSIb3 DQEBAQUABIIBAAdPoj1aTGXctZ/1Xo3tXvk/5ZCQDoZTsYuqTw09fiEPqr4NQAgRgHvEEB9B MkhDoudGOPEVoTLhhcpJZIvep+1kXBurStxxhQ03qfNofxksnthRT+vI32rgJbD7tcZfj89f if5SQrBCRoY6TOw7deRQ0UXErloqKnO2dbkKQhRUEHTK2TNfd73Koj2r+64fu1fpyXS/J8T7 zx5UTbES++27JWpdVm7LhPsV++DYPW40a0AvTGeG+Mhej+x0l8bfeDS7NaGUPP0S7pmHMnHc WH5HemWfde2kEIUIP/7gcP8ZqKde1iwvA30FaOSFrzE2elygpPYl1sp14pNQi2UZlFo= --B_3484028892_75811-- From nobody Tue May 27 06:53:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4691A03A0 for ; Tue, 27 May 2014 06:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBpbtDIveqhH for ; Tue, 27 May 2014 06:53:38 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881B41A0155 for ; Tue, 27 May 2014 06:53:38 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <5383F02F.4050706@nthpermutation.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Tue, 27 May 2014 14:53:29 +0100 To: tls@ietf.org Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m3lcSB4mX38R2iP1mxT8-x-bJq8 Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:53:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 27 May 2014 14:43:31 BST, "Blumenthal, Uri - 0558 - MITLL" wrote: >What would be the consequences of this decision [removing static RSA] for embedded servers >that >may not have a good source of randomness to meaningfully engage in >[EC]DH[E]? If they don't have any source of randomness, they are going to have problems generating any keys, random nonces or IVs, period! I don't think we can usefully do anything secure in that scenario. And I don't think that's a blocker outweighing the very real benefits of mandatory forward security. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJThJjZGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6eC4QAKFzD6fu/jVOzHB/OkhCml1hnyPCWOfF8AHWt5EALqAUdBAyzRpU PYyAOMuyQ9cXdv3tZfetZDgIioSkiO0gCaPlhzgpeNvWxAtM2AaU8uzUhar54MAX /7RqbbtXhjduy/O2SZ3252n5WbQnjJOpescY48hMp4f4DvvDrQK5+AWJF1shf7i7 nDnuf5JT0LMx0aqIhbarRnkxhTARLJJnq9VoTg7IRg6XcnwArwLkjupMb7vOFheF nHrEo33CsfrJN4Hjxxoe/DacxUid3I4+Md+9ZZBxLdJEj1dmN2OazX/ZoN2yuS9T 1K/4jzdcskncktMyBx4neYQA/KkNHiHiaXzdoFkykhP0E+S7uLj3XZ00B4AZYKuU O0m8TNadfKGXob1dpFdW8SD+yTt7O7WWj05UrySr9KJUjSzWXqu169wOXkmwViIZ ld/Fnzg5LVXFGYbWNstWDZO8m+4Cwx9f8hkxTHGFV2PAKa8deGcQZ+5Y3QCwdYuK 4r7skoXAHUmk4D0XxmS/NFn7+v2D/o6AVLx9yzjCB+c9T5zy6N2CO0uAXaYb9gJa 1KRcEw3s1hrBnS3BKDbV+GIQgl2zv/OYXD5VVJQ1G1ltUmNtidjrMYJr1KUy0TXZ k6MAJWSjsaJXposKvR3nSCAsxWC++4jescOUcAiYTSAMpdnd2Zy2jU/T =5Lby -----END PGP SIGNATURE----- From nobody Tue May 27 06:57:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338FD1A0137 for ; Tue, 27 May 2014 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAictp8Mlwn7 for ; Tue, 27 May 2014 06:57:38 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194661A014C for ; Tue, 27 May 2014 06:57:37 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1764172wib.13 for ; Tue, 27 May 2014 06:57:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qUadrVg+O46nSoBQXw/w3aUTkbiBP7koDB8wIbPNI54=; b=bOKIeox7+oetwH5gezR3epXRv2/Dg9D0I7i4gVhRKKwA+jRON7w9vvV5Q2fv07lTZP HTiV6G5e2SvI1YMCcd9C67084blp0uGH05Ajpkew1RDFE+S0BIrFpF3isSwZeWi83qO4 jXSoVG9GEzKB54MCrlbznPGU/w47slWDl91p7ge8PQEs17JuOV/ONDwaVYOF00kgnJNO 28Cnmig5XrKW1IhCaTLpZp0uyhLurLH9+1I75bRAu6KXkW0mVF8HYSfyFjaWSkkEY9YI /wK7gZ99/VYS1fg5na68pWMU+nJyb8dyZA5Cfvv7DrMkEn8cs4ZCupx9T+oSILbjsyQd BXXA== X-Gm-Message-State: ALoCoQlSu+yvrUrviuFdlBqvvTYG5lRt6L8h0dT6WC5ZJ8aXPKAYur4LxWDmeCkuJbxShVeGX0sX X-Received: by 10.194.187.107 with SMTP id fr11mr38127569wjc.70.1401199050622; Tue, 27 May 2014 06:57:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 27 May 2014 06:56:50 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <5383F02F.4050706@nthpermutation.com> From: Eric Rescorla Date: Tue, 27 May 2014 06:56:50 -0700 Message-ID: To: "Blumenthal, Uri - 0558 - MITLL" Content-Type: multipart/alternative; boundary=047d7bb03f60ac215c04fa621309 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ng4141F9IuWrjWjgcdccpnl9Y6U Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:57:40 -0000 --047d7bb03f60ac215c04fa621309 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL < uri@ll.mit.edu> wrote: > >...... Could someone confirm > >"removing static RSA" results in removing the use of RSA as a key > >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of > >TLS1.2 - basically removing this section and prohibiting "rsa" and > >"rsa_psk" as key exchange algorithms)? > > > >To go further and take this up from specific cryptography - will/should > >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key > >Agreement mechanisms for key exchange? > > What would be the consequences of this decision for embedded servers that > may not have a good source of randomness to meaningfully engage in > [EC]DH[E]? > They will be in trouble. However, presumably if they have a place to store their private key, they can somehow store other random data there that they use to generate random values, no? -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7bb03f60ac215c04fa621309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL <uri@= ll.mit.edu> wrote:
>...... Could someone confirm
>"removing static RSA" results in removing the= use of =C2=A0RSA as a key
>transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of
>TLS1.2 - basically removing this section and prohibiting "rsa"= ; and
>"rsa_psk" =C2=A0as key exchange algorithms)?
>
>To go further and take this up from specific cryptography - will/should=
>TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key
>Agreement mechanisms for key exchange?

What would be the consequences of this decision for embedded servers = that
may not have a good source of randomness to meaningfully engage in
[EC]DH[E]?

They will be in trouble. How= ever, presumably if they have a place to store
their private key,= they can somehow store other random data there that
they use to = generate random values, no?

-Ekr
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--047d7bb03f60ac215c04fa621309-- From nobody Tue May 27 07:00:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3D11A03FF for ; Tue, 27 May 2014 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goaUWHtHgl76 for ; Tue, 27 May 2014 07:00:20 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id E5C991A011D for ; Tue, 27 May 2014 07:00:19 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RE0AvF030396; Tue, 27 May 2014 10:00:14 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Alyssa Rowan , "tls@ietf.org" Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPebMRVncNd1CgFUOlioqIt8R1f5tUdGoA Date: Tue, 27 May 2014 13:59:47 +0000 Message-ID: References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484029582_117650" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-27_02:2014-05-26,2014-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270195 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O4nd72Adtnz4r9FklJ2LynEiHTE Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:00:27 -0000 --B_3484029582_117650 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit >>What would be the consequences of this decision [removing static RSA] >>for embedded servers >>That may not have a good source of randomness to meaningfully engage in >>[EC]DH[E]? > >If they don't have any source of randomness, they are going to have >problems generating any keys, random nonces or IVs, period! Respectfully disagree. Keys: manufacturer can generate random key pairs for such devices and burn them in. IVs: contrary to what some people tend to believe, IV does not have to be random (or even unpredictable). Being unique is sufficient in many cases, including AEAD. >I don't think we can usefully do anything secure in that scenario. Again, respectfully disagree. >And I don't think that's a blocker outweighing the very real benefits of >mandatory forward security. I do. I prefer an option with explicit lack of PFS rather than "PFS on paper only". --B_3484029582_117650 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCBiJBICjijnSpK/gnblMISC7hO+MNcsnFIQLgeDJwtuVzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxMzU5NDJaMA0GCSqGSIb3 DQEBAQUABIIBAGSSELp9KpgVofbF6ybe75/PGyvO9gg2AQQV3n/qWLbGLic8GzdPQoy1P7fV N3NkgsfOVnojhKThsKein+JqNKi/6Le09qT5GM3S3JReF2sCWn2f3uKjEu1ne5/gCXqLrbgy WF4HgUc8wn8PDStCCBP7cyUCpzcmHPqTSQos1aHo6bG94O4n9hjD5ph4yr3AppO5F2x1BJSH J7UHHRJKEoz45fZPx/GaNLhGUg7YSc+e908Sa0DjHRZ6rObezancAu/Ie2kUsfllehk7bF50 kJDRQkYpiWjfoLI9X+NoHFSDltr9XRUu1E/z1Kii+rCVOZJvRUqipQTTCIiNMECCrhQ= --B_3484029582_117650-- From nobody Tue May 27 07:00:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459D51A034E for ; Tue, 27 May 2014 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65C8-WUnD9Ah for ; Tue, 27 May 2014 07:00:52 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED691A0354 for ; Tue, 27 May 2014 07:00:52 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id a41so7476525yho.7 for ; Tue, 27 May 2014 07:00: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:date:message-id:subject:from:to :cc:content-type; bh=1szYJS5qFGSBjg+QzkWaX5xVjYpeKhksVoqIux0//j4=; b=aY8FO8P5MLI7xU6oF1xKnLj7sHtUoyCNgRr27huTWFmm6IFCV9ib64brreNJFSV7vX LrEPij4Gf8WbcIgyRbKBvLIqAeAnM0i3oPgD6yWWJvejhY38ugVB7KBUJbSwoguk58rZ yUlpRIcjZIXh5Vwgp3DjRrNuAW3u5dbf/dqrzFVN52tiOywDXHLd+AodM14n+oUygwBD La59Z8LzuN9v9h61p00G5NVdp7RUad3lbfX5Qrqu9qU3qtgncVBpaeqoC2V+2vrWN9So dwEiJ6Bn46KtrLESe8V5eNZ8CorWBoMQm19jYSV7eWKYcofqtFjKyEDzhgGj/ZfD8E2m jyEw== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr46715640yhh.66.1401199249140; Tue, 27 May 2014 07:00:49 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Tue, 27 May 2014 07:00:49 -0700 (PDT) In-Reply-To: References: <5383F02F.4050706@nthpermutation.com> Date: Tue, 27 May 2014 07:00:49 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iQI1yCuiEfQhv9aJRg5l8dFCV0w Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:00:55 -0000 On Tue, May 27, 2014 at 6:56 AM, Eric Rescorla wrote: > > > > On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL > wrote: >> >> >...... Could someone confirm >> >"removing static RSA" results in removing the use of RSA as a key >> >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of >> >TLS1.2 - basically removing this section and prohibiting "rsa" and >> >"rsa_psk" as key exchange algorithms)? >> > >> >To go further and take this up from specific cryptography - will/should >> >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key >> >Agreement mechanisms for key exchange? >> >> What would be the consequences of this decision for embedded servers that >> may not have a good source of randomness to meaningfully engage in >> [EC]DH[E]? > > > They will be in trouble. However, presumably if they have a place to store > their private key, they can somehow store other random data there that > they use to generate random values, no? But then they can store an incrementing counter for use with AES with a fixed key as a RNG. I don't see the problem here. > > -Ekr > >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue May 27 07:10:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2856D1A042B for ; Tue, 27 May 2014 07:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJA17MowlLkV for ; Tue, 27 May 2014 07:10:31 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id E90161A0425 for ; Tue, 27 May 2014 07:10:30 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4REAHHu011033 for ; Tue, 27 May 2014 10:10:26 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPebOboqr8ZFQSiEKtD3KU9grzFZtUt8eA//+/dwA= Date: Tue, 27 May 2014 14:09:55 +0000 Message-ID: References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484030190_165830" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-27_02:2014-05-26,2014-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270196 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fHn4FeyOPZv6moVYRzxcEDMT2fw Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:10:33 -0000 --B_3484030190_165830 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit >>>What would be the consequences of [removing key transport] for embedded >>>servers that >>> may not have a good source of randomness to meaningfully engage in >>> [EC]DH[E]? >> >> >> They will be in trouble. However, presumably if they have a place to >>store >> their private key, they can somehow store other random data there that >> they use to generate random values, no? > >But then they can store an incrementing counter for use with AES with >a fixed key as a RNG. I don't see the problem here. Yes, that is definitely an option (why didn't I think of it myself?) - a reasonably good PRNG for a source of randomness. However I still am uneasy about the client being unable to tell the server "This is *my* transaction, and I want you to use this key with this cipher suite to protect it". [I understand the value of PFS. :-] --B_3484030190_165830 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCDKvqrFYhY/jJ21jpON7NcgZBuS7lKAG06M2nUYT50i6DAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxNDA5NTBaMA0GCSqGSIb3 DQEBAQUABIIBAF+NbKDrO5ViOT1k5dDzY+Il4/Z8+wzOs7K+o+v2cHWaI+5VxqBfEU3OxoWh HVDm3+xAvdKudsjseRew80cG57GB5YvLSsLcVWX2/McLILsHBLt3hxkAlBWiXzdawxmDtSNx rpBet5WLrwh3MvuJCRraXurrL3/lp+LROgiwBg3zkRGdqieZ+qhcPWzmw8l58Elj/77bNbnz Dm/xY3FUGbdBIAhVGAda8HLVkuLURiIGugHk3mlNLL5iRKvriM9VX0W4iaW1Ic3WsaJUWid5 Me/wte2bW5qYfVJlFu0r96r/nDBYGfTHiwF1TzdtuwmcqrkQT5iagQ3YySKF8Bx2Ni4= --B_3484030190_165830-- From nobody Tue May 27 07:11:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425BF1A034E for ; Tue, 27 May 2014 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY8ZUsfsHNsj for ; Tue, 27 May 2014 07:11:27 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695D51A0137 for ; Tue, 27 May 2014 07:11:27 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id cc10so1814560wib.4 for ; Tue, 27 May 2014 07:11:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vSaImjdpx4OytSdwqwfj9J6U5Mp7gEpav2cSjMd+RT4=; b=hCgIzfh+zmBWotH/ldfWMHY6Tv1nzz+tdpIOClG/FW/UsmC2GvBMpT/ZYOliAxrzpm ytkFJjcVo/NRDFcktmfdSnQMI1+zsfgiwZhDx6jznVq2lvQA7cZ7fGHYkJLiT+a80nyI 4t5YTwKzeOYE+PPfrMBwbQDlc7tBJivhViLyLgBx9ZF0tDCxf1DLaakcWDsOrkUb+mzk grkfDxs+bFc+E6+tU3UrNdfijs2zGAQCoK5qyyUA/WGgj51CuKkJjfhby4gCHehiqeZu vTifAvijR2p9p981G/cEWVoS5GIWMBA/dSqjq8RO71gDj4vTB3CFyN+zSGN743XPSNML Ruvw== X-Gm-Message-State: ALoCoQkZFyXk0l4PLe+wmwR6W18wgVeHn+VHppy8dQu+B8JsOt0m6Fm0xMKSVPzNxql/ejv2NiuT X-Received: by 10.180.93.234 with SMTP id cx10mr23156683wib.18.1401199880699; Tue, 27 May 2014 07:11:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 27 May 2014 07:10:40 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <5383F02F.4050706@nthpermutation.com> From: Eric Rescorla Date: Tue, 27 May 2014 07:10:40 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d04388e17261c0304fa62456a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1NHAIg91lfXhEcEqkfsH8U4Q2HM Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:11:35 -0000 --f46d04388e17261c0304fa62456a Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 7:00 AM, Watson Ladd wrote: > On Tue, May 27, 2014 at 6:56 AM, Eric Rescorla wrote: > > > > > > > > On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL > > wrote: > >> > >> >...... Could someone confirm > >> >"removing static RSA" results in removing the use of RSA as a key > >> >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of > >> >TLS1.2 - basically removing this section and prohibiting "rsa" and > >> >"rsa_psk" as key exchange algorithms)? > >> > > >> >To go further and take this up from specific cryptography - will/should > >> >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key > >> >Agreement mechanisms for key exchange? > >> > >> What would be the consequences of this decision for embedded servers > that > >> may not have a good source of randomness to meaningfully engage in > >> [EC]DH[E]? > > > > > > They will be in trouble. However, presumably if they have a place to > store > > their private key, they can somehow store other random data there that > > they use to generate random values, no? > > But then they can store an incrementing counter for use with AES with > a fixed key as a RNG. I don't see the problem here. Yes, that is one way of doing what i was suggesting. -Ekr --f46d04388e17261c0304fa62456a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, May 27, 2014 at 7:00 AM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Tue, May 27, 2014 at 6:56= AM, Eric Rescorla <ekr@rtfm.com>= wrote:
>
>
>
> On Tue, May 27, 2014 at 6:43 AM, Blumenthal, Uri - 0558 - MITLL
> <uri@ll.mit.edu> wrote: >>
>> >...... Could someone confirm
>> >"removing static RSA" results in removing the use of= =C2=A0RSA as a key
>> >transport mechanism from 1.3 (e.g. as defined in section 7.4.7= .1 of
>> >TLS1.2 - basically removing this section and prohibiting "= ;rsa" and
>> >"rsa_psk" =C2=A0as key exchange algorithms)?
>> >
>> >To go further and take this up from specific cryptography - wi= ll/should
>> >TLS 1.3 prohibit *any* Key Transport mechanism and retain only= Key
>> >Agreement mechanisms for key exchange?
>>
>> What would be the consequences of this decision for embedded serve= rs that
>> may not have a good source of randomness to meaningfully engage in=
>> [EC]DH[E]?
>
>
> They will be in trouble. However, presumably if they have a place to s= tore
> their private key, they can somehow store other random data there that=
> they use to generate random values, no?

But then they can store an incrementing counter for use with AES with=
a fixed key as a RNG. I don't see the problem here.
Yes, that is one way of doing what i was suggesting.

-Ekr
--f46d04388e17261c0304fa62456a-- From nobody Tue May 27 07:18:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115801A042F for ; Tue, 27 May 2014 07:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bQ1uat_W_ap for ; Tue, 27 May 2014 07:18:28 -0700 (PDT) Received: from mx-out-1.rwth-aachen.de (mx-out-1.rwth-aachen.de [134.130.5.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB51A1A0429 for ; Tue, 27 May 2014 07:18:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,919,1392159600"; d="scan'208";a="322580035" Received: from hub2.rwth-ad.de (HELO mail.rwth-aachen.de) ([134.130.26.143]) by mx-1.rz.rwth-aachen.de with ESMTP; 27 May 2014 16:18:23 +0200 Received: from localhost.localdomain (78.49.182.208) by mail.rwth-aachen.de (134.130.26.143) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 27 May 2014 16:18:23 +0200 Message-ID: <53849EAE.1000103@rwth-aachen.de> Date: Tue, 27 May 2014 16:18:22 +0200 From: Jakob Breier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-PMWin-Version: 3.1.1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/umtlaWxDxMYa7Xty6HcD1v5ljOA Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:18:31 -0000 On 05/27/2014 04:00 PM, Watson Ladd wrote: >> >They will be in trouble. However, presumably if they have a place to store >> >their private key, they can somehow store other random data there that >> >they use to generate random values, no? > But then they can store an incrementing counter for use with AES with > a fixed key as a RNG. I don't see the problem here. Even better, if there is some memory that can be securely erased, you could retain PFS via something like r_(j+1) = HMAC(longTermKey, r_j || counter ) where the cache of the current random output r_j will be overwritten with r_(j+1). Regards, Jakob Breier From nobody Tue May 27 07:29:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B421A042A for ; Tue, 27 May 2014 07:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Enlrwj_EAkV for ; Tue, 27 May 2014 07:29:09 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAEA1A015E for ; Tue, 27 May 2014 07:29:08 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 May 2014 10:29:01 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Tue, 27 May 2014 10:29:00 -0400 From: Dan Brown To: "'Jakob.Breier@rwth-aachen.de'" , "'tls@ietf.org'" Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPebG6jS62b94+bkCFOdj7VQoBAZtUtq4AgAABHYCAAATnAP//vytg Date: Tue, 27 May 2014 14:29:00 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C88570@XMB116CNC.rim.net> References: <5383F02F.4050706@nthpermutation.com> <53849EAE.1000103@rwth-aachen.de> In-Reply-To: <53849EAE.1000103@rwth-aachen.de> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01CF7996.79037A00" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CiBXQFFr-XbDuLsvARPqy9emmOQ Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:29:15 -0000 ------=_NextPart_000_000A_01CF7996.79037A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looks like PRNGs, e.g. HMAC_DRBG, being re-invented, by the way. > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Jakob Breier > Sent: Tuesday, May 27, 2014 10:18 AM > To: tls@ietf.org > Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD > > On 05/27/2014 04:00 PM, Watson Ladd wrote: > >> >They will be in trouble. However, presumably if they have a place to > >> >store their private key, they can somehow store other random data > >> >there that they use to generate random values, no? > > But then they can store an incrementing counter for use with AES with > > a fixed key as a RNG. I don't see the problem here. > > Even better, if there is some memory that can be securely erased, you could > retain PFS via something like > r_(j+1) = HMAC(longTermKey, r_j || counter ) where the cache of the current > random output r_j will be overwritten with r_(j+1). > > Regards, > Jakob Breier > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_000A_01CF7996.79037A00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyNzE0Mjg1OVowIwYJKoZIhvcNAQkEMRYEFKYh ACQt3Z9adGXvWqNds4vqhADgMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYDiXTs1P9Dv/BhuJ8WyT23u4kedTrQe aMwEGj62OfTLS6szgoW90uOiNJ0sJ3U4wtLZMoGktQkF8PuQFd+YggD3dPPEhC2Z2CCVG57Ylv0+ 2kK2rlObve/PKc00HFyJKb+eCMXyoj9ZqWoKAGgKa7MgN2XQ5I6J/FmQH0wWbkvHrgAAAAAAAA== ------=_NextPart_000_000A_01CF7996.79037A00-- From nobody Tue May 27 07:52:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93431A015F for ; Tue, 27 May 2014 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBZgN1c39LBI for ; Tue, 27 May 2014 07:52:51 -0700 (PDT) Received: from mx-out-2.rwth-aachen.de (mx-out-2.rwth-aachen.de [134.130.5.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D821A0171 for ; Tue, 27 May 2014 07:52:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,919,1392159600"; d="scan'208";a="234541641" Received: from hub1.rwth-ad.de (HELO mail.rwth-aachen.de) ([134.130.26.142]) by mx-2.rz.rwth-aachen.de with ESMTP; 27 May 2014 16:51:48 +0200 Received: from localhost.localdomain (78.49.182.208) by mail.rwth-aachen.de (134.130.26.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 27 May 2014 16:51:47 +0200 Message-ID: <5384A683.6020904@rwth-aachen.de> Date: Tue, 27 May 2014 16:51:47 +0200 From: Jakob Breier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Dan Brown , "'tls@ietf.org'" References: <5383F02F.4050706@nthpermutation.com> <53849EAE.1000103@rwth-aachen.de> <810C31990B57ED40B2062BA10D43FBF5C88570@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5C88570@XMB116CNC.rim.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-PMWin-Version: 3.1.1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jjH_8enOX0mHEeUHIaQZ2ni8iDE Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:52:56 -0000 True :) To just show the principle a simple example is more concise than the full blown HMAC_DRBG, though. Regards, Jakob Breier On 05/27/2014 04:29 PM, Dan Brown wrote: > Looks like PRNGs, e.g. HMAC_DRBG, being re-invented, by the way. > >> -----Original Message----- >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Jakob Breier >> Sent: Tuesday, May 27, 2014 10:18 AM >> To: tls@ietf.org >> Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and > AEAD >> On 05/27/2014 04:00 PM, Watson Ladd wrote: >>>>> They will be in trouble. However, presumably if they have a place to >>>>> store their private key, they can somehow store other random data >>>>> there that they use to generate random values, no? >>> But then they can store an incrementing counter for use with AES with >>> a fixed key as a RNG. I don't see the problem here. >> Even better, if there is some memory that can be securely erased, you > could >> retain PFS via something like >> r_(j+1) = HMAC(longTermKey, r_j || counter ) where the cache of the > current >> random output r_j will be overwritten with r_(j+1). >> >> Regards, >> Jakob Breier >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Tue May 27 08:18:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D64A1A00F9 for ; Tue, 27 May 2014 08:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg5H9M5VxBrk for ; Tue, 27 May 2014 08:18:30 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB41A034E for ; Tue, 27 May 2014 08:18:27 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 May 2014 11:18:20 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Tue, 27 May 2014 11:18:19 -0400 From: Dan Brown To: "tls@ietf.org" Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPebG6jS62b94+bkCFOdj7VQoBAZtUfXPg Date: Tue, 27 May 2014 15:18:19 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net> References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000F_01CF799D.5B4DDE90" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZfQe0Zobl7NQhi91ggYQo5ijqNE Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:18:31 -0000 ------=_NextPart_000_000F_01CF799D.5B4DDE90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Blumenthal, Uri - > 0558 - > MITLL > Sent: Tuesday, May 27, 2014 9:44 AM > > >...... Could someone confirm > >"removing static RSA" results in removing the use of RSA as a key > >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of > >TLS1.2 - basically removing this section and prohibiting "rsa" and > >"rsa_psk" as key exchange algorithms)? > > > >To go further and take this up from specific cryptography - will/should > >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key > >Agreement mechanisms for key exchange? > > What would be the consequences of this decision for embedded servers that > may not have a good source of randomness to meaningfully engage in > [EC]DH[E]? As noted elsewhere, if the server is authenticated (or at least has a long-term private key) and has a persistent state then it should be able to implement a good PRNG. Then it can do pretty good DHE, with forward secrecy, which is better than key transport. Otherwise, static [ECH]DH seems quite similar in security properties to key transport, from the server's side, for the following 2 reasons. If the server is completely stateless and lacks an entropy source, it will fail to achieve FS in its attempts at DH[E], but this is still as good as key transport. If the server is anonymous, (or at least lacks a long-term private key) and lacks a source of entropy, a persistent state does not seem to help, whether for DH or RSA key exchanged. --- A different question: what about very constrained clients? Is this even a fair question? For example, what if the client can be seeded with entropy but lacks a live entropy source and a persistent state (to implement a good PRNG)? Currently key transport require the client to generate a random pre_master_secret. A weak client could naively always generate the same PMS, which would be bad. It could derive the PMS from the server key public key, and perhaps the server random value, so that PMS is not common to two different servers, or sessions. This would make it similar to static DH. An even weaker client is one that is unseeded and entropy-lacking (and completely stateless, not that statefulness would help here). Such a client could apply deterministic encryption of messages using RSA. Note that this would no longer be key transport, but rather content encryption, so would require a major change to TLS. Also, this type of deterministic encryption lacks many of the important security benefits of probabilistic encryption. There have been research papers about deterministic encryption: the security is limited by the amount of entropy in the message being encrypted. Anyway, maybe this is the one situation in which RSA has an advantage over DH. ------=_NextPart_000_000F_01CF799D.5B4DDE90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyNzE1MTgxNlowIwYJKoZIhvcNAQkEMRYEFEEn XT2pPbaihckQUUxGCGThn0p3MG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYDAolk7wChXcB+56awRjAbTyL36ga4y hvk/5Cc1jQzegPa0/x64Lfh7nVAuEy0435fZsY29gwWiYPws8sdjVxRJP18LFSUe+hRkOQARjWCi Oqaf0C63wMJfL6eNr3RU6t57MiRhdwN2Qj+EErRvgJ425mGlbq9AVGEIwAIoRPOYYwAAAAAAAA== ------=_NextPart_000_000F_01CF799D.5B4DDE90-- From nobody Tue May 27 08:20:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6321A0176 for ; Tue, 27 May 2014 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0e6YOWTgRw0 for ; Tue, 27 May 2014 08:20:48 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07181A0455 for ; Tue, 27 May 2014 08:20:44 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so7557362yha.4 for ; Tue, 27 May 2014 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KXY2THDgRa9gQjF/uVIzRx10nynkDKcdYcFO2Fh/Gbk=; b=QELX5fZ+rkJD/DpHa33oJY+gdbN+FAbSGcS7yIc0J/Ss20xpwezEdNKrm1Jug+yrTm 7tyKVKUoFgIAsr5RIDmF9dSQHVgKxdz9W357keuyTgZ+6mUTODrN92OmeWnghSNh8qUR ak2RuWyI4u3qlT12VvXRkaP74tiZOryNi4c1IzeJRoWM2jEROCphnJcoFZMD/zLmomBg 3yaji7HJXpwruzWtpJpHEUipkvKb9fff0M2xXy/bUEAZLhFQIID8PsgvKH6imdZJYDTQ p8vpjClwkfN5m48f3b5SCPYWpmy5OOXPfdfXKs5LKyB1sDUY4Bg/ExxxOZkSHTBOmQ8f U5xw== MIME-Version: 1.0 X-Received: by 10.236.50.229 with SMTP id z65mr15105282yhb.120.1401204041172; Tue, 27 May 2014 08:20:41 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Tue, 27 May 2014 08:20:41 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Tue, 27 May 2014 08:20:41 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net> References: <5383F02F.4050706@nthpermutation.com> <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net> Date: Tue, 27 May 2014 08:20:41 -0700 Message-ID: From: Watson Ladd To: Dan Brown Content-Type: multipart/alternative; boundary=089e01634d8a21cb5504fa633d5a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-Ucn5O1qy7uM5bWdKMFiHmt6VL8 Cc: tls@ietf.org Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:20:51 -0000 --089e01634d8a21cb5504fa633d5a Content-Type: text/plain; charset=UTF-8 On May 27, 2014 8:18 AM, "Dan Brown" wrote: > > > -----Original Message----- > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Blumenthal, Uri - > > 0558 - > > MITLL > > Sent: Tuesday, May 27, 2014 9:44 AM > > > > >...... Could someone confirm > > >"removing static RSA" results in removing the use of RSA as a key > > >transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of > > >TLS1.2 - basically removing this section and prohibiting "rsa" and > > >"rsa_psk" as key exchange algorithms)? > > > > > >To go further and take this up from specific cryptography - will/should > > >TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key > > >Agreement mechanisms for key exchange? > > > > What would be the consequences of this decision for embedded servers that > > may not have a good source of randomness to meaningfully engage in > > [EC]DH[E]? > > > As noted elsewhere, if the server is authenticated (or at least has a > long-term private key) and has a persistent state then it should be able to > implement a good PRNG. Then it can do pretty good DHE, with forward secrecy, > which is better than key transport. > > Otherwise, static [ECH]DH seems quite similar in security properties to key > transport, from the server's side, for the following 2 reasons. > > If the server is completely stateless and lacks an entropy source, it will > fail to achieve FS in its attempts at DH[E], but this is still as good as key > transport. > > If the server is anonymous, (or at least lacks a long-term private key) and > lacks a source of entropy, a persistent state does not seem to help, whether > for DH or RSA key exchanged. > Replay attacks: servers need state or randomness to prevent. > --- > > A different question: what about very constrained clients? Is this even a > fair question? > > For example, what if the client can be seeded with entropy but lacks a live > entropy source and a persistent state (to implement a good PRNG)? > > Currently key transport require the client to generate a random > pre_master_secret. A weak client could naively always generate the same PMS, > which would be bad. It could derive the PMS from the server key public key, > and perhaps the server random value, so that PMS is not common to two > different servers, or sessions. This would make it similar to static DH. > > An even weaker client is one that is unseeded and entropy-lacking (and > completely stateless, not that statefulness would help here). Such a client > could apply deterministic encryption of messages using RSA. Note that this > would no longer be key transport, but rather content encryption, so would > require a major change to TLS. Also, this type of deterministic encryption > lacks many of the important security benefits of probabilistic encryption. > There have been research papers about deterministic encryption: the security > is limited by the amount of entropy in the message being encrypted. Anyway, > maybe this is the one situation in which RSA has an advantage over DH. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e01634d8a21cb5504fa633d5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 27, 2014 8:18 AM, "Dan Brown" <dbrown@certicom.com> wrote:
>
> > -----Original Message-----
> > From: TLS [mailto:tls-bou= nces@ietf.org] On Behalf Of Blumenthal, Uri -
> > 0558 -
> > MITLL
> > Sent: Tuesday, May 27, 2014 9:44 AM
> >
> > >...... Could someone confirm
> > >"removing static RSA" results in removing the use o= f =C2=A0RSA as a key
> > >transport mechanism from 1.3 (e.g. as defined in section 7.4.= 7.1 of
> > >TLS1.2 - basically removing this section and prohibiting &quo= t;rsa" and
> > >"rsa_psk" =C2=A0as key exchange algorithms)?
> > >
> > >To go further and take this up from specific cryptography - w= ill/should
> > >TLS 1.3 prohibit *any* Key Transport mechanism and retain onl= y Key
> > >Agreement mechanisms for key exchange?
> >
> > What would be the consequences of this decision for embedded serv= ers that
> > may not have a good source of randomness to meaningfully engage i= n
> > [EC]DH[E]?
>
>
> As noted elsewhere, if the server is authenticated (or at least has a<= br> > long-term private key) and has a persistent state then it should be ab= le to
> implement a good PRNG. =C2=A0Then it can do pretty good DHE, with forw= ard secrecy,
> which is better than key transport.
>
> Otherwise, static [ECH]DH seems quite similar in security properties t= o key
> transport, from the server's side, for the following 2 reasons. >
> If the server is completely stateless and lacks an entropy source, it = will
> fail to achieve FS in its attempts at DH[E], but this is still as good= as key
> transport.
>
> If the server is anonymous, (or at least lacks a long-term private key= ) and
> lacks a source of entropy, a persistent state does not seem to help, w= hether
> for DH or RSA key exchanged.
>

Replay attacks: servers need state or randomness to prevent.=

> ---
>
> A different question: =C2=A0what about very constrained clients? =C2= =A0Is this even a
> fair question?
>
> For example, what if the client can be seeded with entropy but lacks a= live
> entropy source and a persistent state (to implement a good PRNG)?
>
> Currently key transport require the client to generate a random
> pre_master_secret. =C2=A0A weak client could naively always generate t= he same PMS,
> which would be bad. =C2=A0It could derive the PMS from the server key = public key,
> and perhaps the server random value, so that PMS is not common to two<= br> > different servers, or sessions. =C2=A0This would make it similar to st= atic DH.
>
> An even weaker client is one that is unseeded and entropy-lacking (and=
> completely stateless, not that statefulness would help here). =C2=A0 S= uch a client
> could apply deterministic encryption of messages using RSA. =C2=A0Note= that this
> would no longer be key transport, but rather content encryption, so wo= uld
> require a major change to TLS. Also, this type of deterministic encryp= tion
> lacks many of the important security benefits of probabilistic encrypt= ion.
> There have been research papers about deterministic encryption: the se= curity
> is limited by the amount of entropy in the message being encrypted. = =C2=A0Anyway,
> maybe this is the one situation in which RSA has an advantage over DH.=
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--089e01634d8a21cb5504fa633d5a-- From nobody Tue May 27 08:53:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870CF1A043D for ; Tue, 27 May 2014 08:53:24 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7muTUCdhUhUk for ; Tue, 27 May 2014 08:53:21 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1261A0193 for ; Tue, 27 May 2014 08:53:21 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id ey11so9353574pad.4 for ; Tue, 27 May 2014 08:53:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=VHs24BQujt+L5hyFGUl72LpjPWWsC9uds96IZ8RQnck=; b=f7sUMpODhtjuYDZkETIfABOOwge07LpVMHqMyn1xA3b5x3caMZn2ye++uqJb2mOJ2M CK2wohMj/V6c/HJAkeF+jujIGyTwxOTAkv6aoIwm7LTsclkJ8VaDrsq9BRNl9KCnzQIJ OPt7Oerm9ychzdl17GiK7OYoiaDyQaThlWtrId1I2QDHuxBXk4oDer2SfRvmpXqZ1dde jPPYoc6xRakY48Ev+KU+KPjHiq19KkGmsQPYQkrweyih4qmBdn8m3c9i1c+diXozTqGW 3Qe+i7ewGGbR2ZEmPSnyFhqNH1vw+8w1Wp7hjia6rc2nZBVotv7phsOcij+NtAz6rcyq jXwg== X-Gm-Message-State: ALoCoQkvE3zd98Q8sbOqgEmSxS8n31YMi+M1djFJPwrPEJWMW95hyySNpH450Bhgg9be/ajs9Upo X-Received: by 10.66.122.208 with SMTP id lu16mr36075979pab.129.1401205998517; Tue, 27 May 2014 08:53:18 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id xk1sm75148252pac.21.2014.05.27.08.53.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 08:53:17 -0700 (PDT) Message-ID: <5384B4F4.9040109@nthpermutation.com> Date: Tue, 27 May 2014 11:53:24 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eric Rescorla References: <5383F02F.4050706@nthpermutation.com> <53840318.10902@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090607050406040909030402" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xjRZl-zZhHxku_VpHJLAZFNp_7U Cc: "tls@ietf.org" Subject: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:53:24 -0000 This is a multi-part message in MIME format. --------------090607050406040909030402 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/26/2014 11:25 PM, Eric Rescorla wrote: > On Mon, May 26, 2014 at 8:14 PM, Michael StJohns > > wrote: > > On 5/26/2014 10:32 PM, Eric Rescorla wrote: >> >> Does it also result in changing the output of the "key >> expansion" phase as only "client_write_key" and >> "server_write_key"s will be needed for AEAD? >> >> >> I don't believe so, since AEAD still at least potentially >> requires an IV. > > Right - but we really need to get IV material in a way where it > isn't derived from the master secret. > > > I don't agree with this claim. As I understand the constraints, they > merely > need to be derived in a way that is isolated from the keying material. > Is there a reason that it's unsafe to generate the IVs from the MS > provided > that this condition is met? I'm going to answer this twice because EKR's comment appears to include an slight internal inconsistency or I'm mis-understanding what he meant: 1) ---------------------------------- "isolated from the keying material" can be accomplished one of two ways - by deriving a sub-secret from the master secret and then using that for generating the IV in a keyed PRNG, or by deriving a second secret from the pre-master secret at the same time you generate the master secret and generating the IV from that second secret. I would claim that neither of those is equivalent to "generate the IV's from the MS...." There's a third way that basically injects per-key and iv length information into the KDF expansion - I looked at this and rejected it as it made the KDF security analysis complex and it violated the general principle that cryptographic functions output either public (cipher text, signatures) or private data (key material) and not both. Is there a fourth way you were thinking of? and "isolated" needs to mean "cryptographically isolated". 2) ---------------------------------- As a specific comment on how the master secret is used: The general rule is that the same key shouldn't be used for multiple things. In this case the master secret is used (ignoring for a moment that the functions are all iterations of the PRF): * with a Key Derivation Function to derive key material * with a MAC function to sign the finished messages * with a keyed pseudo random number generator to derive the IV's. By my count that's two too many. The fact that the KDF and PRNG steps are part of the same process is even more problematic. There's literature on this - but an easy reference is section 5.2 of NIST's SP800-57 part 1 rev 3 - http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1: > 5.2 Key Usage > In general, a single key should be used for only one purpose (e.g., > encryption, authentication, > key wrapping, random number generation, or digital signatures). There > are several reasons for > this: > 1. The use of the same key for two different cryptographic processes > may weaken the > security provided by one or both of the processes. > 2. Limiting the use of a key limits the damage that could be done if > the key is compromised. > 3. Some uses of keys interfere with each other. For example, consider > a key pair used for > both key transport and digital signatures. In this case, the private > key is used as both a > private key-transport key to decrypt data-encryption keys and a > private signature key to > apply digital signatures. It may be necessary to retain the private > key-transport key > beyond the cryptoperiod of the corresponding public key-transport key > in order to decrypt > the data-encryption keys needed to access encrypted data. On the other > hand, the private > signature key shall be destroyed at the expiration of its cryptoperiod > to prevent its > compromise (see Section 5.3.6). In this example, the longevity > requirements for the > private key-transport key and the private digital-signature key > contradict each other. > This principle does not preclude using a single key in cases where the > same process can provide > multiple services. This is the case, for example, when a digital > signature provides assurance of > the identity of the originating entity, non-repudiation, source > authentication and integrity > protection using a single digital signature, or when a single > symmetric data-encryption key can > be used to encrypt and authenticate data in a single cryptographic > operation (e.g., using an > authenticated-encryption operation, as opposed to separate encryption > and authentication > operations). Also refer to Section 3.7. > This Recommendation also permits the use of a private key-transport or > key-agreement key to > generate a digital signature for the following special case: > When requesting the (initial) certificate for a static > key-establishment key, the associated > private key may be used to sign the certificate request. Also refer to > Section 8.1.5.1.1.2. Because the IV may be used for things like nonces, the IV generator needs to be unpredictable, but able to be generated synchronously from data available to the sender and receiver. It's unclear that it needs any more entropy (e.g. a key) than that available in the client_random and server_random. If the per-message IV is carried in its entirety in the message, then the IV generator need not be coordinated between sender and receiver. From a general cryptographic point of view, an IV is NOT a confidential data element. A cipher mode is required to be secure even if the IV is available to an attacker, so again, it's unclear the IV generator needs to be a keyed PRNG. Mike --------------090607050406040909030402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/26/2014 11:25 PM, Eric Rescorla wrote:
On Mon, May 26, 2014 at 8:14 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 5/26/2014 10:32 PM, Eric Rescorla wrote:
Does it also result in changing the output of the "key expansion" phase as only "client_write_key" and "server_write_key"s will be needed for AEAD?

I don't believe so, since AEAD still at least potentially requires an IV.

Right - but we really need to get IV material in a way where it isn't derived from the master secret.  

I don't agree with this claim. As I understand the constraints, they merely
need to be derived in a way that is isolated from the keying material.
Is there a reason that it's unsafe to generate the IVs from the MS provided
that this condition is met?


I'm going to answer this twice because EKR's comment appears to include an slight internal inconsistency or I'm mis-understanding what he meant:

1) ----------------------------------

"isolated from the keying material" can be accomplished one of two ways - by deriving a sub-secret from the master secret and then using that for generating the IV in a keyed PRNG, or by deriving a second secret from the pre-master secret at the same time you generate the master secret and generating the IV from that second secret.  I would claim that neither of those is equivalent to "generate the IV's from the MS...."

There's a third way that basically injects per-key and iv length information into the KDF expansion - I looked at this and rejected it as it made the KDF security analysis complex and it violated the general principle that cryptographic functions output either public (cipher text, signatures) or private data (key material) and not both.

Is there a fourth way you were thinking of? and "isolated" needs to mean "cryptographically isolated".


2) ----------------------------------

As a specific comment on how the master secret is used:

The general rule is that the same key shouldn't be used for multiple things.  In this case the master secret is used (ignoring for a moment that the functions are all iterations of the PRF):
  • with a Key Derivation Function to derive key material
  • with a MAC function to sign the finished messages
  • with a keyed pseudo random number generator to derive the IV's.
By my count that's two too many.  The fact that the KDF and PRNG steps are part of the same process is even more problematic.

There's literature on this - but an easy reference is section 5.2 of NIST's SP800-57 part 1 rev 3 - http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1:

5.2 Key Usage
In general, a single key should be used for only one purpose (e.g., encryption, authentication,
key wrapping, random number generation, or digital signatures). There are several reasons for
this:

1. The use of the same key for two different cryptographic processes may weaken the
security provided by one or both of the processes.

2. Limiting the use of a key limits the damage that could be done if the key is compromised.

3. Some uses of keys interfere with each other. For example, consider a key pair used for
both key transport and digital signatures. In this case, the private key is used as both a
private key-transport key to decrypt data-encryption keys and a private signature key to
apply digital signatures. It may be necessary to retain the private key-transport key
beyond the cryptoperiod of the corresponding public key-transport key in order to decrypt
the data-encryption keys needed to access encrypted data. On the other hand, the private
signature key shall be destroyed at the expiration of its cryptoperiod to prevent its
compromise (see Section 5.3.6). In this example, the longevity requirements for the
private key-transport key and the private digital-signature key contradict each other.

This principle does not preclude using a single key in cases where the same process can provide
multiple services. This is the case, for example, when a digital signature provides assurance of
the identity of the originating entity, non-repudiation, source authentication and integrity
protection using a single digital signature, or when a single symmetric data-encryption key can
be used to encrypt and authenticate data in a single cryptographic operation (e.g., using an
authenticated-encryption operation, as opposed to separate encryption and authentication
operations). Also refer to Section 3.7.

This Recommendation also permits the use of a private key-transport or key-agreement key to
generate a digital signature for the following special case:
When requesting the (initial) certificate for a static key-establishment key, the associated
private key may be used to sign the certificate request. Also refer to Section 8.1.5.1.1.2.

Because the IV may be used for things like nonces, the IV generator needs to be unpredictable, but able to be generated synchronously from data available to the sender and receiver.  It's unclear that it needs any more entropy (e.g. a key)  than that available in the client_random and server_random.  If the per-message IV is carried in its entirety in the message, then the IV generator need not be coordinated between sender and receiver.

From a general cryptographic point of view, an IV is NOT a confidential data element.  A cipher mode is required to be secure even if the IV is available to an attacker, so again, it's unclear the IV generator needs to be a keyed PRNG.

Mike


--------------090607050406040909030402-- From nobody Tue May 27 09:04:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BBC1A0487 for ; Tue, 27 May 2014 09:03:59 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wUrpzjD3boK for ; Tue, 27 May 2014 09:03:57 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4611A04C8 for ; Tue, 27 May 2014 09:02:59 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp16so9431144pbb.6 for ; Tue, 27 May 2014 09:02:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=ILeIubBhfKHoxQjQTHAEdPxcbG9LfhQS3h0KknwhzsI=; b=Cc1VK3V3DZbl+lQGaK4IBG89gh6uGSkhkBABJ4JDbl5FUG8QFVbTPLsj0U50gI9BFY G8qnDpVFgoKEgO88RQEJ0ZWnFcSvkPVVSq5u8zzrVYOcaHUaQmbLbNVTN5YKB5/D2jQt pYdiW9SaJVPAinPB+UmmKZQmuwQqJmCB6CZUoLb0ZJsdMnSwXfvKk90/A5RVTLrHT9pZ DDWwBmSue7cDZIX1yOTfkditw/A67swzbNgpjXkeyUC+XPonUHlc24J2WSrY4MSBNv8Z jGXRAUUK2S73W2zyVuXiJnfKj2JPTsXlb44vFZlihtUtaKzG6tlRlpuZO41olU///gN5 3P3A== X-Gm-Message-State: ALoCoQmG0dNzTqBhjPktOST0tBMCewjKNwHte7vl7hcTDC2vVx+wVGi013qzUyEJfDG7dJTZqhPF X-Received: by 10.66.189.226 with SMTP id gl2mr37681532pac.65.1401206575068; Tue, 27 May 2014 09:02:55 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id iq10sm24018215pbc.14.2014.05.27.09.02.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 09:02:54 -0700 (PDT) Message-ID: <5384B735.3090904@nthpermutation.com> Date: Tue, 27 May 2014 12:03:01 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0558 - MITLL" , Eric Rescorla References: <5383F02F.4050706@nthpermutation.com> <53840318.10902@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080706060208040100080804" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kJIGQYIV_37ckTlSiH5OWjo-vLM Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 16:03:59 -0000 This is a multi-part message in MIME format. --------------080706060208040100080804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/27/2014 9:39 AM, Blumenthal, Uri - 0558 - MITLL wrote: > >> Does it also result in changing the output of the "key >> expansion" phase as only "client_write_key" and >> "server_write_key"s will be needed for AEAD? >> >> >> I don't believe so, since AEAD still at least potentially >> requires an IV. > > Right - but we really need to get IV material in a way where > it isn't derived from the master secret. > > > s/isn't derived/is cryptographically separated/ > > And everything will be fine. ;) No. The key material and IVs produced by the current TLS1.2 KDF are "cryptographically separated" from the master secret - that's sort of the definition of what a KDF is. You want cryptographic isolation between the key material produced from the master secret and the iv material produced from the IV, and the current spec doesn't do that. See my last message to EKR. One way to create this isolation is to derive the random IV data from a key that is different from the master secret - either a subkey derived from the master secret, or from a second key derived from the premaster. A second way to create the isolation is to not generate the IV data from a key value and instead simply use an entropy expansion function on the client_random and server_random to generate the IVs. There are other approaches, but most end up with a single function producing both public and private data and that makes securing the process difficult. Mike > > I don't agree with this claim. As I understand the constraints, > they merely > need to be derived in a way that is isolated from the keying material. > > > Yes. > > Is there a reason that it's unsafe to generate the IVs from the MS > provided > that this condition is met? > > > IMHO, no. :-) --------------080706060208040100080804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/27/2014 9:39 AM, Blumenthal, Uri - 0558 - MITLL wrote:
Does it also result in changing the output of the "key expansion" phase as only "client_write_key" and "server_write_key"s will be needed for AEAD?

I don't believe so, since AEAD still at least potentially requires an IV.

Right - but we really need to get IV material in a way where it isn't derived from the master secret.  

s/isn't derived/is cryptographically separated/

And everything will be fine. ;)

No.  The key material and IVs produced by the current TLS1.2 KDF are "cryptographically separated" from the master secret - that's sort of the definition of what a KDF is.  

You want cryptographic isolation between the key material produced from the master secret and the iv material produced from the IV, and the current spec doesn't do that.  See my last message to EKR.  One way to create this isolation is to derive the random IV data from a key that is different from the master secret - either a subkey derived from the master secret, or from a second key derived from the premaster.    A second way to create the isolation is to not generate the IV data from a key value and instead simply use an entropy expansion function on the client_random and server_random to generate the IVs.

There are other approaches, but most end up with a single function producing both public and private data and that makes securing the process difficult.

Mike





I don't agree with this claim. As I understand the constraints, they merely
need to be derived in a way that is isolated from the keying material.

Yes.

Is there a reason that it's unsafe to generate the IVs from the MS provided
that this condition is met?

IMHO, no. :-)

--------------080706060208040100080804-- From nobody Tue May 27 09:59:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E1B1A0537 for ; Tue, 27 May 2014 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl2fOlEMIC1P for ; Tue, 27 May 2014 09:59:04 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id A4B331A04B6 for ; Tue, 27 May 2014 09:59:04 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RGwpFO004894; Tue, 27 May 2014 12:59:00 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Michael StJohns , Eric Rescorla Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD Thread-Index: AQHPeVP+xhSBxDY3A06EGaypXGdrtptUA/QAgAADGgCAAGhfgIAAaz2A///MhYA= Date: Tue, 27 May 2014 16:58:54 +0000 Message-ID: References: <5383F02F.4050706@nthpermutation.com> <53840318.10902@nthpermutation.com> <5384B735.3090904@nthpermutation.com> In-Reply-To: <5384B735.3090904@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.25.177.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484040325_781880" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-27_05:2014-05-26,2014-05-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270228 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xupO3RK_dZmRfSRvaRzdazGrB8Q Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 16:59:06 -0000 --B_3484040325_781880 Content-type: multipart/alternative; boundary="B_3484040325_792032" --B_3484040325_792032 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit > You want cryptographic isolation between the key material produced from the > master secret and the iv material produced from the IV, and the current spec > doesn't do that. See my last message to EKR. One way to create this > isolation is to derive the random IV data from a key that is different from > the master secret - either a subkey derived from the master secret, or from a > second key derived from the premaster. You want the separation to be on a higher level. I'd be happy with either one of the above. > A second way to create the isolation is to not generate the IV data from a > key value and instead simply use an entropy expansion function on the > client_random and server_random to generate the IVs. Should be fine too, assuming at least one *_random is good enough. --B_3484040325_792032 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable <= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
You want cryptographic isolation between the key material produ= ced from the master secret and the iv material produced from the IV, and the= current spec doesn't do that.  See my last message to EKR.  One w= ay to create this isolation is to derive the random IV data from a key that is different from the master secret - either a sub= key derived from the master secret, or from a second key derived from the pr= emaster.  

You = want the separation to be on a higher level.

I'd be= happy with either one of the above.

  A second way to create the isolation is to= not generate the IV data from a key value and instead simply use an entropy expansion function on the client_random and server_r= andom to generate the IVs.

Should be fine too, assuming at least one *_random is good enough.

--B_3484040325_792032-- --B_3484040325_781880 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCCW3yFfkkyEd83FuYurMLdDNcXduaXGke/VBb3RweKpPjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxNjU4NDVaMA0GCSqGSIb3 DQEBAQUABIIBAEUGhtxz/tUtpR/nNo114Q8Xz4wf7jLLRurxMQDx3kKlqIhykhy6YqiSlGc0 OviCedikU0P2j/G4afIIvbBVV9Y13CsmCRkZJCVYCXn12tm4OR5uXz4lTyU+6ch0Ev+lco1F qfG1EUT/Gu21ERAttDvEn/rJVugtuLMsPhjdiGdXfagyVA+O/rNUER2QD0EPTPkPn90Rq1/Y J/frLP67s0Wcq+/9TCapeFNIb+IQg6aFDRUENm0sFrVcD0qxDEOxY13+rCHk+TUsoUXa0f39 TnPL5MjlgwMAsSNHWi9+3CuXAnHxGAgAoscmHrX2ltd6zGlCl9Y/zoRNZtSEuGIwuA8= --B_3484040325_781880-- From nobody Tue May 27 10:24:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FEE1A0545 for ; Tue, 27 May 2014 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEOrsXaslP4l for ; Tue, 27 May 2014 10:24:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65821A01D5 for ; Tue, 27 May 2014 10:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12840; q=dns/txt; s=iport; t=1401211451; x=1402421051; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=wZgSpKBudlGHzpalIzH0Goe/2iCEQF3xm+RFs8mzCWQ=; b=Z2npHjSQ98dROtEaxSPeYR1bQSOFUW98xby9tNbLwWHUAfF2Z8mqe++N X1pN+UvxGSqTNVKef43p6KFXBhQ5IA7g5Ddjb80F+trLcInRw3ukHr+zS sXMbHmgP/V/84Z87DTH7lBjIVvQo9Zwpo7UTt4VEwRD17LdbQ6F5FDvsi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAITJhFOtJA2B/2dsb2JhbABZgwdSWMIagQ8WdIImAQEEJxNPAgE+EDIbCgIEiFUN1SAXi0ODEYRFBI8/ijSTJ4M4bIEDJBw X-IronPort-AV: E=Sophos;i="4.98,920,1392163200"; d="scan'208";a="328063515" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 27 May 2014 17:24:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4RHO9Du010236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 27 May 2014 17:24:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 27 May 2014 12:24:09 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: AUTH48 [AR]: RFC 7250 changes Thread-Index: AQHPedB3r/5JHL+RFEieWpJdLbQeBg== Date: Tue, 27 May 2014 17:24:09 +0000 Message-ID: <790AE3A2-37B2-4124-8093-69812232052C@cisco.com> References: <201405201629.s4KGTtoU021704@new.toad.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D3825A1F1B58A45B33702773D68F49E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l7ViEJQCddZybHlD2Ho35i3XN9I Subject: [TLS] Fwd: AUTH48 [AR]: RFC 7250 changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:24:17 -0000 There have been some small technical changes to draft-ietf-tls-oob-pubkey-1= 1 during the Auth-48 review process. The latest diffs with the most signif= icant changes can be found here: http://www.rfc-editor.org/authors/rfc7250-lastdiff.html and the entire diff from draft 11 is here: http://www.rfc-editor.org/authors/rfc7250-diff.html The rational for the changes is included in the message below. =20 Please review the changes respond on the list if you have any concern by en= d of day Friday, May 30 2014. =20 Thanks, Joe Begin forwarded message from J. Gilmore >=20 > Here is a second message of my suggested updates to RFC 7250 before > publication. Thank you for making the first round of my suggested update= s. >=20 > Please change my affiliation: > OLD: > J. Gilmore >=20 >=20 > New: > J. Gilmore > Electronic Frontier Foundation >=20 > My address is OK as it is. >=20 > Section 4.1: >=20 > OLD: > The client_certificate_type and server_certificate_type extensions sent= in > the client hello may carry a list of supported certificate types, > sorted by client preference. It is a list when the client supports > multiple certificate types. >=20 > NEW: > The client_certificate_type and server_certificate_type extensions sent= in > the client hello each carry a list of supported certificate types, > sorted by client preference. When the client supports > only one certificate type, it is a list containing a single element. >=20 > Notes: When sent by the client, it is ALWAYS a list. It may be a list > containing one value. When sent by the server, it is always a single > value (chosen from the client's list). >=20 > OLD: >=20 > The TLS client MUST omit the client_certificate_type extension in > the client hello if it does not possess a raw public key or > certificate that it can provide to the server when requested using a > certificate_request message or if it is not configured to use one > with the given TLS server. The TLS client MUST omit the > server_certificate_type extension in the client hello if it is > unable to process raw public keys or other certificate types > introduced via this extension. >=20 > NEW: >=20 > The TLS client MUST omit certificate types from the > client_certificate_type extension in the client hello if it does > not possess the corresponding raw public key or certificate that it > can provide to the server when requested using a > certificate_request message, or if it is not configured to use one > with the given TLS server. If the client has no remaining certificate > types to send in the client hello, other than the default X.509 > type, it MUST omit the client_certificate_type extension in the > client hello. >=20 > The TLS client MUST omit certificate types from the > server_certificate_type extension in the client hello if it is > unable to process the corresponding raw public key or other > certificate type. If the client has no remaining certificate > types to send in the client hello, other than the default > X.509 certificate type, it MUST omit the entire > server_certificate_type extension from the client hello. >=20 > Notes: Three issues in the original text. It mixes discussion of the > client_cert extension with the server_cert extension; I broke those > out into separate paragraphs. Second, the text did not require > clients to avoid advertising capabilities that they are not prepared > to use later. Third, this extension allows further extension by > adding types to the IANA registry, but the wording did not accommodate > that. When prepared to use *any* of the extended types, including > the RawPublicKey type that we define, the already existing > OpenPGP type, and any ones later defined, the TLS client should send > the client_certificate_type extension. (Ditto for the > server_certificate_type extension.) >=20 >=20 > Section 4.3: >=20 > OLD: > Authentication of the TLS client to the TLS server is supported only > through authentication of the received client SubjectPublicKeyInfo > via an out-of-band method. >=20 >=20 > NEW: >=20 > When the TLS server has specified RawPublicKey as the > client_certificate_type, authentication of the TLS client to the > TLS server is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. >=20 > Notes: Other forms of authentication are possible, but not when the > client and server have chosen to use a Raw Public Key certificate. >=20 > Add Section 4.4. Server Authentication >=20 > NEW: > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the > TLS client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. >=20 > Section 5: >=20 > OLD: > Figure 6, Figure 7, and Figure 8 illustrate example exchanges. Note > that TLS ciphersuites using a Diffie-Hellman exchange offering > forward secrecy can be used with raw public keys, although this > document does not show the information exchange at that level with > the subsequent message flows. >=20 > NEW: > Figure 6, Figure 7, and Figure 8 illustrate example exchanges. Note > that TLS ciphersuites using a Diffie-Hellman exchange offering > forward secrecy can be used with a raw public key, although this > document does not show the information exchange at that level with > the subsequent message flows. >=20 > Notes: Use the singular "a raw public key" since the protocol > typically only uses one such key. In general the text has become > slightly confused between singulars and plurals, which adds to the > confusion caused by using a plural list of types in the protocol's > client messages with a singular selection of a type in the otherwise > identical server messages. >=20 > Section 5.1: >=20 > OLD: > 5.1. TLS Server Uses Raw Public Keys >=20 > This section shows an example where the TLS client indicates its > ability to receive and validate raw public keys from the server.=20 >=20 > NEW: > 5.1. TLS Server Uses A Raw Public Key >=20 > This section shows an example where the TLS client indicates its > ability to receive and validate a raw public key from the server.=20 >=20 > Notes: Singularize for a single key. >=20 > OLD: > server_certificate_type=3D(RawPublicKey), // (2) >=20 > NEW: > server_certificate_type=3DRawPublicKey, // (2) >=20 > Notes: The server sends back a single certificate type, not a list, > so it should be shown as a scalar value rather than a single-element list= . >=20 > Section 5.2: >=20 > OLD: > This section shows an example where the TLS client as well as the TLS > server use raw public keys. This is one of the use cases envisioned > for smart object networking. The TLS client in this case is an > embedded device that is configured with a raw public key for use with > TLS and is also able to process raw public keys sent by the server. > Therefore, it indicates these capabilities in (1). As in the > previously shown example, the server fulfills the client's request, > indicates this via the "RawPublicKey" value in the > server_certificate_type payload (2), and provides a raw public key in > the Certificate payload back to the client (see (3)). The TLS > server, however, demands client authentication, and therefore a > certificate_request is added (4). The certificate_type payload in > (5) indicates that the TLS server accepts raw public keys. The TLS > client, who has a raw public key pre-provisioned, returns it in the > Certificate payload (6) to the server. >=20 > NEW: > This section shows an example where the TLS client as well as the TLS > server use raw public keys. This is one of the use cases envisioned > for smart object networking. The TLS client in this case is an > embedded device that is configured with a raw public key for use with > TLS and is also able to process a raw public key sent by the server. > Therefore, it indicates these capabilities in (1). As in the > previously shown example, the server fulfills the client's request, > indicates this via the RawPublicKey value in the > server_certificate_type payload (2), and provides a raw public key in > the Certificate payload back to the client (see (3)). The TLS > server demands client authentication, and therefore includes a > certificate_request (4). The client_certificate_type payload in > (5) indicates that the TLS server accepts a raw public key. The TLS > client, which has a raw public key pre-provisioned, returns it in the > Certificate payload (6) to the server. >=20 > Notes: Use the singular when speaking of a single key. Remove quotes > around "RawPublicKey". Specify which certificate_type payload is being > used to specify the client's certificate type. Do not refer to the=20 > client as a person ("who"), use which instead. >=20 > OLD: > server_certificate_type=3D(RawPublicKey)//(2) > certificate, // (3) > client_certificate_type=3D(RawPublicKey)//(5) >=20 > NEW: > server_certificate_type=3DRawPublicKey // (2) > certificate, // (3) > client_certificate_type=3DRawPublicKey // (5) >=20 > Notes: Show certificate types sent by server as scalars, not lists. >=20 > Section 5.3: >=20 > OLD: > This section shows an example combining raw public keys and X.509 > certificates. The client uses a raw public key for client > authentication, and the server provides an X.509 certificate. This > exchange starts with the client indicating its ability to process > X.509 certificates and raw public keys, if provided by the server. > Additionally, the client indicates that it has a raw public key for > client-side authentication (see (1)). The server provides the X.509 > certificate in (3) with the indication present in (2). For client > authentication, the server indicates in (4) that it selected the raw > public key format and requests a certificate from the client in (5). > The TLS client provides a raw public key in (6) after receiving and > processing the TLS server hello message. >=20 > NEW: This section shows an example combining a raw public key and an > X.509 certificate. The client uses a raw public key for client > authentication, and the server provides an X.509 certificate. This > exchange starts with the client indicating its ability to process > an X.509 certificate, OpenPGP certificate, or a raw public key, if > provided by the server. It prefers a raw public key, since the > RawPublicKey value precedes the other values in the > server_certificate_type vector. Additionally,=20 > the client indicates that it has a raw public key for > client-side authentication (see (1)). The server chooses to provide it= s X.509 > certificate in (3) and indicates that choice in (2). For client > authentication, the server indicates in (4) that it has selected the ra= w > public key format and requests a certificate from the client in (5). > The TLS client provides a raw public key in (6) after receiving and > processing the TLS server hello message. >=20 > Notes: Use the singular where appropriate. Show how OpenPGP would > appear in these exchanges. >=20 > OLD: > server_certificate_type=3D(X.509, RawPublicKey) > client_certificate_type=3D(RawPublicKey) // (1) > -> > <- server_hello, > server_certificate_type=3D(X.509)//(2) > certificate, // (3) > client_certificate_type=3D(RawPublicKey)//(4) >=20 > NEW: > server_certificate_type=3D(RawPublicKey, X.509, OpenPGP) > client_certificate_type=3D(RawPublicKey) // (1) > -> > <- server_hello, > server_certificate_type=3DX.509 // (2) > certificate, // (3) > client_certificate_type=3DRawPublicKey // (4) >=20 > Notes: Show that OpenPGP keys can also participate in this protocol. > Illustrate client preference by the ordering of the vector. Show > server selections as scalars rather than as 1-element lists. >=20 > Thank you! >=20 > John From nobody Tue May 27 10:39:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2150B1A0535 for ; Tue, 27 May 2014 10:39:32 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOo7Fu1v-v5D for ; Tue, 27 May 2014 10:39:30 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E441A04F8 for ; Tue, 27 May 2014 10:39:30 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so9468959pab.24 for ; Tue, 27 May 2014 10:39:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=599oKEikxNddRXMJnew1RCUJid8n67bPv5jOG+mRhrg=; b=R/9nQA2Nxz7OITHMKFW8eo79gNx2g+2peICvWtKrbAi19labHnXFZUXTKuIHIlbAiT +43dfPqsf0UcdvFHlP+ETQ9W2ABdigQOPVWT4sqk8rrdSouZ6fLYNH9Jwt3xbAxo5mfS VpHdQYtP0fKBaU0Zck5O7SxUvezSvc5+UTcm/CH8VHu+Q79uXhrt8Bk8PktAkSj51poU GkkmZaWaOyr0mPpZtbPQQdET6peE1CNDlgzE4lkRbjWf6UTs/Hanh9l6+d3PnyWykSLh uecWGw8hJacshZXNtGr/NJD/M3jTzstx+ESs7HL+6Ozws6zlUWXSPsDmp2kEp0IThnwi RZrQ== X-Gm-Message-State: ALoCoQnSXlnJHJ7X/ggUaDxE0kPWdbEx9D9T//aVN8iuMKx8iPulLtmccELet6l26FsZiRpNqe4B X-Received: by 10.68.193.100 with SMTP id hn4mr38515984pbc.50.1401212367382; Tue, 27 May 2014 10:39:27 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id ih6sm24337104pbc.22.2014.05.27.10.39.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 10:39:26 -0700 (PDT) Message-ID: <5384CDD5.5040306@nthpermutation.com> Date: Tue, 27 May 2014 13:39:33 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0558 - MITLL" , Eric Rescorla References: <5383F02F.4050706@nthpermutation.com> <53840318.10902@nthpermutation.com> <5384B735.3090904@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020605050906040000000701" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dDJ4qqj9yDdcFiDIqXgkGirQkMg Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:39:32 -0000 This is a multi-part message in MIME format. --------------020605050906040000000701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/27/2014 12:58 PM, Blumenthal, Uri - 0558 - MITLL wrote: > > You want cryptographic isolation between the key material produced > from the master secret and the iv material produced from the IV, > and the current spec doesn't do that. See my last message to > EKR. One way to create this isolation is to derive the random IV > data from a key that is different from the master secret - either > a subkey derived from the master secret, or from a second key > derived from the premaster. > > > You want the separation to be on a higher level. > > I'd be happy with either one of the above. > > A second way to create the isolation is to not generate the IV > data from a key value and instead simply use an entropy expansion > function on the client_random and server_random to generate the IVs. > > > Should be fine too, assuming at least one *_random is good enough. > That latter is my preference. --------------020605050906040000000701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/27/2014 12:58 PM, Blumenthal, Uri - 0558 - MITLL wrote:
You want cryptographic isolation between the key material produced from the master secret and the iv material produced from the IV, and the current spec doesn't do that.  See my last message to EKR.  One way to create this isolation is to derive the random IV data from a key that is different from the master secret - either a subkey derived from the master secret, or from a second key derived from the premaster.  

You want the separation to be on a higher level.

I'd be happy with either one of the above.

  A second way to create the isolation is to not generate the IV data from a key value and instead simply use an entropy expansion function on the client_random and server_random to generate the IVs.

Should be fine too, assuming at least one *_random is good enough.


That latter is my preference.
--------------020605050906040000000701-- From nobody Tue May 27 10:43:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51F1A0527 for ; Tue, 27 May 2014 10:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfhOaA_8m64S for ; Tue, 27 May 2014 10:43:48 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5D41A0502 for ; Tue, 27 May 2014 10:43:48 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id jt11so9675455pbb.13 for ; Tue, 27 May 2014 10:43:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0oxgzjJu0CwlW/GB2/8mMaonOAXFhhMrZDBnCWtnRwQ=; b=DOEWP9Ma+OPXskQdeYnUS/QaKXE38LzA+5fst/ACQ0rTY8MqWIEvzPq24G62bkk1mN AaZwFNozIw3E2UE4uMu2k3o5ym/aDVTPyO/LHdHThilqmOJxM5yWekbAfULVUaJMCTao fGOR9AKowZdzMNH38fMFKDRrhwKrQ4cZhayrqb7w7Wzyh6mvvLss2uBEc2nLf+R5/3ht Res93VbGEX0Uu1GhmjRNrW0XDJkzPppGLveXvFD88OAJyyyDIs0c01uBktl9zR2XSBUB 3wpAEGjSuEhAffCmaWZDCip3HQ+l3owKrsYOBtmDH/mVfPHO2U0JV9QV/gJYXPp1/CHn 6P3w== X-Gm-Message-State: ALoCoQm9JGxbIj5w81IZhATeUZ/kWg10KJjgF9lix2OTBH9QMk8YrU3vDdF0Qa3B/rXhXXV47T3g X-Received: by 10.68.200.133 with SMTP id js5mr39033146pbc.138.1401212625404; Tue, 27 May 2014 10:43:45 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id pr4sm24327835pbb.53.2014.05.27.10.43.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 10:43:44 -0700 (PDT) Message-ID: <5384CED8.6030700@nthpermutation.com> Date: Tue, 27 May 2014 13:43:52 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <5383F02F.4050706@nthpermutation.com> <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5C88C49@XMB116CNC.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pJdPrhBwSIzGoGnJBK_WsrJI2UU Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:43:49 -0000 On 5/27/2014 11:18 AM, Dan Brown wrote: > Currently key transport require the client to generate a random > pre_master_secret. A weak client could naively always generate the same PMS, > which would be bad. It could derive the PMS from the server key public key, > and perhaps the server random value, so that PMS is not common to two > different servers, or sessions. This would make it similar to static DH. One of the London decisions (which EKR clarified earlier in the thread) is the removal of key transport (e.g. RSA static encryption) as a key exchange mechanism for TLS1.3. That removes the need to generate a pre_master_secret as the product of only one side. Mike From nobody Tue May 27 10:49:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF271A01D8 for ; Tue, 27 May 2014 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPyKjA_1tB36 for ; Tue, 27 May 2014 10:49:33 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A173C1A0573 for ; Tue, 27 May 2014 10:49:26 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id md12so9625677pbc.12 for ; Tue, 27 May 2014 10:49:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BlwkfllAJ1O5pmkzcxKNrkzz1aA56eRO9v8oJSm9Od4=; b=SUAQmYoJ0gUC4a14Xf0jeFBy3FMW7nnDtfPRZxCBREJYgn9nle6tOUeEvOqbjZnBr8 +iELbgmp2/zXTa4FkP7+RSZuECrNfcMT/fX258NO3nR52HXSayxuMSi09CtfvWhdSHN8 jSMo9Ofk6S/UZW3uDKSIyALbNCe9vCQH+MxXFTohTn7sFA59brRfJc8+HrzJ8/dteoid t63kZzzz/Ya5Blf4/LrCv5EqER+MVHZ8FjL3zZIfGqfv63WPq3cS6x2bv0eQkYZxR9ja +8uyeAPggM7VTBzpHuxBaRYGV2GocucLg5TD/W3mKOSCcYBpQQLvyecdWbPMBVZLEflk HWfw== X-Gm-Message-State: ALoCoQm15rmVjvtBT53mANEAx1GiTVPn/ztNxFxnizhl5MQyQORA42jgIBC1fvzcZ0yHGLNL9Ik+ X-Received: by 10.66.141.165 with SMTP id rp5mr38934734pab.90.1401212963542; Tue, 27 May 2014 10:49:23 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id io6sm76297637pac.44.2014.05.27.10.49.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 10:49:22 -0700 (PDT) Message-ID: <5384D029.5080902@nthpermutation.com> Date: Tue, 27 May 2014 13:49:29 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QMyJIEC8JjUnVqhHQUCmw7I5_G4 Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:49:34 -0000 On 5/27/2014 9:59 AM, Blumenthal, Uri - 0558 - MITLL wrote: > IVs: contrary to what some people tend to believe, IV does not have to be > random (or even unpredictable). Being unique is sufficient in many cases, > including AEAD. Hi Uri - I seem to remember for some modes that the IV has to unpredictable - I believe that CBC was one. (But may be mitigated by integrity checks to defeat chosen plain text attacks? I don't have time to search for a cite). You are correct that uniqueness is the only requirement for AEAD, but mostly AEAD IVs are constructed from a [random nonce][per message value][block counter 0] concatenation - the random nonce enforces the uniquity. Mike From nobody Tue May 27 10:58:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70AB1A063F for ; Tue, 27 May 2014 10:58:19 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCOx9iLmm16Y for ; Tue, 27 May 2014 10:58:15 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572F91A0584 for ; Tue, 27 May 2014 10:58:01 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id jt11so9696050pbb.13 for ; Tue, 27 May 2014 10:57:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=cwcuEbqwyAqgPYUZTrsaXlq2YXWrg9kOS0Ez92C36UI=; b=Yi3IDpO6ncZHQOzS01D9l2MiPRcDTbrQABpAtPxQfOEIO5l5tDajMHKV1VT33v3az5 fLlN8Gy1fcGbRIPtcz7q9Zy/rBfJSvykN6BSJKI/Glz1OewF3nDpEbEfW0ZHBGEp6ygb +5wZUS/cn5KrYoV82W34qWmaCxdUDd0+lDTPTW+mHS+8rvOsJP/mhl6CfPDck5tlp0AA okPycBkDbPLEiDC3YmTrbHvRvb5l0wfOovYQe0X7taekDGk8zZPA8qqQVEo1YHVUCsTO KYezUrsFeadqEFP/hBNaQwuxAUYwQ/r0KS3HzPbTsmkCWOGRVmF3VILdy/DcRurgkawd I2qw== X-Gm-Message-State: ALoCoQmyg79kg8dn+dQCI8KZ5fl75TEXZtfybCHL1LbfLF2FM8BVScFSyBEOivoi8px216/EZPGS X-Received: by 10.68.231.196 with SMTP id ti4mr39052286pbc.48.1401213478229; Tue, 27 May 2014 10:57:58 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id zv3sm76444622pab.20.2014.05.27.10.57.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 10:57:57 -0700 (PDT) Message-ID: <5384D22C.907@nthpermutation.com> Date: Tue, 27 May 2014 13:58:04 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <5383F02F.4050706@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060705000104080503040201" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/735hxvFHr-qt0XVWFpDSgfTIvd8 Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:58:20 -0000 This is a multi-part message in MIME format. --------------060705000104080503040201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/27/2014 9:43 AM, Blumenthal, Uri - 0558 - MITLL wrote: >> ...... Could someone confirm >> "removing static RSA" results in removing the use of RSA as a key >> transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of >> TLS1.2 - basically removing this section and prohibiting "rsa" and >> "rsa_psk" as key exchange algorithms)? >> >> To go further and take this up from specific cryptography - will/should >> TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key >> Agreement mechanisms for key exchange? > What would be the consequences of this decision for embedded servers that > may not have a good source of randomness to meaningfully engage in > [EC]DH[E]? You could still do 1/2 ephemeral ECDH. The embedded server would have to have a key pair created for it and installed, and would have to only support ECDHE ciphers. The client would generate a new ECDH pair per connection, resulting in different derived shared secrets. It's not ideal, but has the benefit of not requiring much in the way of randomness. You still need a source of some randomness for server_random though. The comments elsewhere on using a seeded AES PRNG are interesting - but it would be useful to still mix in as much entropy as you can find internally. (Or even externally). Mike > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------060705000104080503040201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/27/2014 9:43 AM, Blumenthal, Uri - 0558 - MITLL wrote:
...... Could someone confirm
"removing static RSA" results in removing the use of  RSA as a key
transport mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of
TLS1.2 - basically removing this section and prohibiting "rsa" and
"rsa_psk"  as key exchange algorithms)?

To go further and take this up from specific cryptography - will/should
TLS 1.3 prohibit *any* Key Transport mechanism and retain only Key
Agreement mechanisms for key exchange?

What would be the consequences of this decision for embedded servers that
may not have a good source of randomness to meaningfully engage in
[EC]DH[E]?

You could still do 1/2 ephemeral ECDH.  The embedded server would have to have a key pair created for it and installed, and would have to only support ECDHE ciphers.  The client would generate a new ECDH pair per connection, resulting in different derived shared secrets.  It's not ideal, but has the benefit of not requiring much in the way of randomness.

You still need a source of some randomness for server_random though.  The comments elsewhere on using a seeded AES PRNG are interesting - but it would be useful to still mix in as much entropy as you can find internally.  (Or even externally). 

Mike



      

      

      

      
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

  


--------------060705000104080503040201--


From nobody Tue May 27 11:01:54 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C921A0650 for ; Tue, 27 May 2014 11:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level: 
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnx7EhSOROxN for ; Tue, 27 May 2014 11:01:47 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 91E891A01BB for ; Tue, 27 May 2014 11:01:38 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RI1MC8031212; Tue, 27 May 2014 14:01:34 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Michael StJohns , "tls@ietf.org" 
Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
Thread-Index: AQHPebMRVncNd1CgFUOlioqIt8R1f5tUdGoAgACDQYD//8BHAA==
Date: Tue, 27 May 2014 18:01:31 +0000
Message-ID: 
References: <5383F02F.4050706@nthpermutation.com>    <5384D029.5080902@nthpermutation.com>
In-Reply-To: <5384D029.5080902@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [172.25.177.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484044084_1004680"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-05-27_05:2014-05-26,2014-05-27,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270242
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VCrcci-ke5rKT7_Ve87XquSL2uM
Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 18:01:53 -0000

--B_3484044084_1004680
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit

On 5/27/14 13:49 , "Michael StJohns"  wrote:

>On 5/27/2014 9:59 AM, Blumenthal, Uri - 0558 - MITLL wrote:
>> IVs:  contrary to what some people tend to believe, IV does not have to
>>be
>> random (or even unpredictable). Being unique is sufficient in many
>>cases,
>> including AEAD.
>
>Hi Uri -
>
>I seem to remember for some modes that the IV has to unpredictable - I
>believe that CBC was one. (But may be mitigated by integrity checks to
>defeat chosen plain text attacks?

Yes and yes. AFAIR. Which is why I'm not a fan of CBC (in addition to
having to worry about padding :).

>I don't have time to search for a
>cite).  You are correct that uniqueness is the only requirement for
>AEAD, but mostly AEAD IVs are constructed from a [random nonce][per
>message value][block counter 0] concatenation - the random nonce
>enforces the uniqueness.

Random nonce = per-key-change. Per-message value could be also a counter.

;)

--B_3484044084_1004680
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP
8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5
pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi
ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj
akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu
ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T
eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m
1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2
BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ
NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk
u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK
PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y
MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4
YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C
PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2
QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D
1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB
kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB
BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE
VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ
BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ
iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw
7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8
c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt
DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX
X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE
BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET
MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG
SIb3DQEJBDEiBCD1i+RoFwuDOJ/qXonG0xtEe4bvHZtCOfJxo0flDvPPBjAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxODAxMjRaMA0GCSqGSIb3
DQEBAQUABIIBAInlOghGzfQ0I032JO4gw9TLFvQiGJpzAo9bwUQWljO3hrkwEh7Qyab2A1zP
BATLjkc3pONTp8ShdJL4NmBzHppCxGTh2GvDH0wZ1UzEeaQdar5gXe8a6QjRz9sTDoviqxLH
oW9479RdZDzXpMFvyIb2TzUlJllpqKLENLbmRO4CGjkuqNFarq3jwLbS6E6hEs1dEVHTiYQs
xZAM6F9OOAXCuN09AVVHK8bKVJIX9bWogxw2qsJLzM1VxuywZGRJyP0yiMGH8LklEbV8q1Y6
rY4xY9fQ1R8QEmdHxscavwSL2oDNWV0yBMk31LTOivxILxOEdgkeSTArgXAyLRLG/oI=

--B_3484044084_1004680--


From nobody Tue May 27 11:10:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D381A063A for ; Tue, 27 May 2014 11:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcAiNvTwtiBk for ; Tue, 27 May 2014 11:10:22 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487471A04F8 for ; Tue, 27 May 2014 11:10:22 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F5AB2AB10A; Tue, 27 May 2014 18:10:17 +0000 (UTC)
Date: Tue, 27 May 2014 18:10:17 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20140527181017.GN27883@mournblade.imrryr.org>
References: <201405201629.s4KGTtoU021704@new.toad.com> <790AE3A2-37B2-4124-8093-69812232052C@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <790AE3A2-37B2-4124-8093-69812232052C@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FnBSZvbufkBsuEVQiY4M2NMZnEc
Subject: Re: [TLS] Fwd: AUTH48 [AR]: RFC 7250  changes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 18:10:23 -0000

On Tue, May 27, 2014 at 05:24:09PM +0000, Joseph Salowey (jsalowey) wrote:

> > Section 4.3:
> > 
> > OLD:
> >   Authentication of the TLS client to the TLS server is supported only
> >   through authentication of the received client SubjectPublicKeyInfo
> >   via an out-of-band method.
> > 
> > NEW:
> > 
> >   When the TLS server has specified RawPublicKey as the
> >   client_certificate_type, authentication of the TLS client to the
> >   TLS server is supported only through authentication of the received
> >   client SubjectPublicKeyInfo via an out-of-band method.
> > 
> > [...]
> > 
> > Add Section 4.4.  Server Authentication
> > 
> > NEW:
> >   When the TLS server has specified RawPublicKey as the
> >   server_certificate_type, authentication of the TLS server to the
> >   TLS client is supported only through authentication of the received
> >   client SubjectPublicKeyInfo via an out-of-band method.

Some (as I did briefly, though I think I have finally figured out
what is meant) might find "authentication" here a bit confusing.

There are two parts to the traditional use of a public key in TLS for
authentication:

    * The public key is used to sign the key exchange or decrypt
      key transport.  This proves that the counter-party possesses
      the corresponding private key.

    * The public key is delivered in the form of a certificate that
      attests to a binding between the public key and some identity.

When I first read the quoted text out of context, I though it was
saying that both parts were out of band, which is surely not the
case.  Rather it is merely the identity mapping that is out of
band, each side still verifies possession via appropriate signatures.

Is the use of raw public keys to sign the relevant bits of the
handshake that would otherwise have been signed by the public key
embedded in the certificate too obvious to have to state explicitly?

-- 
	Viktor.


From nobody Tue May 27 12:01:50 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFFD1A06D0 for ; Tue, 27 May 2014 12:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrYaYy0aaFcy for ; Tue, 27 May 2014 12:01:36 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBE71A06F3 for ; Tue, 27 May 2014 12:01:31 -0700 (PDT)
Message-ID: <5384E0EE.4050703@akr.io>
Date: Tue, 27 May 2014 20:01:02 +0100
From: Alyssa Rowan 
MIME-Version: 1.0
To: tls@ietf.org
References: <5383F02F.4050706@nthpermutation.com>   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T-0gM2udsktrkMPrMjfynXdVPCY
Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 19:01:40 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 27/05/2014 14:59, Blumenthal, Uri - 0558 - MITLL wrote:

>> If they don't have any source of randomness, they are going to
>> have problems generating any keys, random nonces or IVs, period!
> Keys: manufacturer can generate random key pairs for such devices
> and burn them in.

I caution against such a practice. Pre-baked keys are a half-baked idea!

Pre-baked keys make the manufacturer responsible for not just the
implementation, but the actual keys.

• If the manufacturer keeps the keys:
  - The manufacturer will become a remarkably attractive target.
  - The manufacturer will be attacked - legally, technically, and
    otherwise, by various actors - for the keys.
  - Manufacturers are unlikely to be able to resist every attack.

• If the manufacturer "doesn't keep the keys":
  - The manufacturer may not generate the keys securely.
  - The manufacturer is likely to be coerced into secretly keeping
    the keys, or may already be doing so.
  - The manufacturer may be, or may be coerced into, lying about it.
  - The manufacturer cannot prove they didn't keep the keys.

This has represented - and still represents - the most significant
practical point of attack in numerous real-world implementations (to
give one notable high-profile example: the seed compromise in RSA
SecurID®).

I would strongly recommend device manufacturers not to generate keys.

> IVs:  contrary to what some people tend to believe, IV does not
> have to be random (or even unpredictable). Being unique is
> sufficient in many cases, including AEAD.

A note of caution here: as I recall, CBC mode's one of the famous
problem cases where non-random IVs enable a chosen-ciphertext attack?

[Of course, no AEAD I'm aware of uses CBC mode, so I believe we're
switching away from that in TLS 1.3 - but still, the point bears
mention in case of later misunderstanding.]

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJThODtAAoJEOyEjtkWi2t6e/wP/jjoSssPOtvruCGphHwucYOD
r5GSmCBSc18LYHpVEIDoWcjekMJGuCbh6Ox0FjPuSOWg8rr6tkFeWNciFPUea6lG
aCU2ympklkrVZSD1Aj1UpOAuj64R1waXIfn/s6+lw7hQLDJo9iwsmI9NmOdXxYTd
9pJXKNX6GTzlJ7x7U0Kl4D9TO+oMWtlr3TngNONwH4lFazCvpOfeTQPmA2Rgof5L
ulYAykOam/ATEb32gz82c8wzZvK7/DLc+M0siCbaRxtCUGOUkaO+zhg1wzWHI4rK
/3s54SIWtfydmEhxGu6zqIrHu8vrGurLYQDfYVn8FqbXERSobmXMpJC1Qv3SqcNR
YnURYlQpzBs0sHU85EtZUzZQ3anUu5f4b8CmT1UAObRcw2Sh7f3P66XdJstbc4km
r2+eZSvNYhaS2Rnh3WW6KxIIU8yrnNTqUhETs1tchmOd28rsYgkuWFjdUk6ZdxEH
CSWTpyFehNpbLKVXLjpTdlAMs8ezwdE9WgUS4nW5lC7677Q4LiymtHGem+LQMX00
cEFH3DcCewHQI0+tXVWkgwqU4z3Sw/EJKejDEqDzbNHLaemORweplnHzJLWLLONS
kDv55xPfGGMbmSB9V4UZyvY/6FZ1O7grsAP9Q8a/EmA60OklOZ+VyCYRKxSx/S1M
OOxS6FYeMEMfiVEV0W/h
=1IBh
-----END PGP SIGNATURE-----


From nobody Tue May 27 12:17:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F111A06FD for ; Tue, 27 May 2014 12:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vnduz-ffrFJ for ; Tue, 27 May 2014 12:17:48 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4434E1A0698 for ; Tue, 27 May 2014 12:17:44 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id rq2so9766568pbb.17 for ; Tue, 27 May 2014 12:17:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GVLxeMdrbq8hNI/ygugoY4BWwTwhDiRam/JBvuWzGj4=; b=cHQU2cvfxOUtntxKqLFnGyaZu4Lz4+1GHeGgo0LIVw0Mmx/QerjE0orMpdIQ0Qa08B Kbbdd3j7WmuHLJzm8JhN6thdEu8u0081eXeFpoPRim9ygCwxTgSkqQ0GBdAkez0DPyv+ UZVkHOjbnAuaiuU6rk9Kbq8NZvMKySe2aWP1nLG/oN6E1I2jgMbEeIhsWmK3zQFlr7XS NoeCYDc7nItmsvJoQTSe/LsrS9VsiD07XOz34/ZGfe5gNuQ1ysyII65qjHCbYAgHBmIC QoTAjh1xc4zYiyTsB15ZZHAym+OTW3uGAi0BSyQqLqhLR6onIuE4IKBH2Afm3R1pddHN DpOQ==
X-Gm-Message-State: ALoCoQlF/iZrKVWLdY828M57nTsiYed41WffWQNcIkp0M1lY6zhWehtZI2Np8ilKQfvmi2e4IydL
X-Received: by 10.68.134.69 with SMTP id pi5mr32665769pbb.126.1401218260949; Tue, 27 May 2014 12:17:40 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id fu12sm77169874pad.42.2014.05.27.12.17.38 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 12:17:39 -0700 (PDT)
From: Andy Lutomirski 
X-Google-Original-From: Andy Lutomirski 
Message-ID: <5384E4D2.2010302@mit.edu>
Date: Tue, 27 May 2014 12:17:38 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Blumenthal, Uri - 0558 - MITLL" ,  Alyssa Rowan , "tls@ietf.org" 
References: <5383F02F.4050706@nthpermutation.com>   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EUvNX39yz9MDT3wBtf_udkE8E6w
Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 19:17:52 -0000

On 05/27/2014 06:59 AM, Blumenthal, Uri - 0558 - MITLL wrote:
>>> What would be the consequences of this decision [removing static RSA]
>>> for embedded servers
>>> That may not have a good source of randomness to meaningfully engage in
>>> [EC]DH[E]?
>>
>> If they don't have any source of randomness, they are going to have
>> problems generating any keys, random nonces or IVs, period!
> 
> Respectfully disagree.
> 
> Keys: manufacturer can generate random key pairs for such devices and burn
> them in.

Which means that, if the device is ever a TLS client using an TLS
1.1-style RSA key transport, then the device is completely insecure: the
supposedly secret part of the pre-master secret will always be the same!

If the device really has no source of randomness, I think it's still
much better off using a static DHE secret.

--Andy


From nobody Tue May 27 12:32:19 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A41A071B for ; Tue, 27 May 2014 12:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.25
X-Spam-Level: 
X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUaTnN0sdbAM for ; Tue, 27 May 2014 12:32:16 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id CA76A1A06EA for ; Tue, 27 May 2014 12:32:15 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4RJVqA8028927 for ; Tue, 27 May 2014 15:32:11 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
Thread-Index: AQHPebMRVncNd1CgFUOlioqIt8R1f5tUdGoAgACXPwD//8WUAA==
Date: Tue, 27 May 2014 19:32:01 +0000
Message-ID: 
References: <5383F02F.4050706@nthpermutation.com>    <5384E0EE.4050703@akr.io>
In-Reply-To: <5384E0EE.4050703@akr.io>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [172.25.177.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484049516_1352091"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-05-27_05:2014-05-26,2014-05-27,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405270263
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l6Q3iDqx-M-XBKSPb4BBd-z_g6Y
Subject: Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 19:32:18 -0000

--B_3484049516_1352091
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

>>>If they don't have any source of randomness, they are going to
>>> have problems generating any keys, random nonces or IVs, period!
>> Keys: manufacturer can generate random key pairs for such devices
>> and burn them in.
>
>I caution against such a practice.......
>Pre-baked keys make the manufacturer responsible for not just the
>implementation, but the actual keys.
>..............

Conceptually, is it different from manufacturer seeding the PRNG on such
devices?

>This has represented - and still represents - the most significant
>practical point of attack in numerous real-world implementations (to
>give one notable high-profile example: the seed compromise in RSA
>SecurID=C2=AE).
>
>I would strongly recommend device manufacturers not to generate keys.

It may be the only reasonable alternative for small-factor embedded
devices, the other alternative being very bad keys generated on such
devices locally.=20

I think most of the bad SSH and TLS keys reported on the Internet are the
result of such approach being implemented.

"A good man knows his limitations" - this should apply to good devices
too. :)


See=20
@InProceedings{weakkeys12,
  author =3D {Nadia Heninger and Zakir Durumeric and Eric Wustrow and J.
Alex Halderman},
  title =3D {Mining Your {P}s and {Q}s: {D}etection of Widespread Weak Keys
in Network Devices},
  booktitle =3D {Proceedings of the 21st {USENIX} Security Symposium},
  month =3D aug,
  year =3D 2012
}


>>IVs:  contrary to what some people tend to believe, IV does not
>> have to be random (or even unpredictable). Being unique is
>> sufficient in many cases, including AEAD.
>
>A note of caution here: as I recall, CBC mode's one of the famous
>problem cases where non-random IVs enable a chosen-ciphertext attack?

Essentially yes. But it is not just CBC mode, it's a combination of the
usage, cipher suite, etc. I.e., if the MAC was in a better place wrt.
Pad+Encrypt and all this, y'know...

I personally would rather drop CBC than RSA. :-)

>[Of course, no AEAD I'm aware of uses CBC mode, so I believe we're
>switching away from that in TLS 1.3 - but still, the point bears
>mention in case of later misunderstanding.]

Of course. :-0

--B_3484049516_1352091
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP
8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5
pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi
ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj
akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu
ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T
eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m
1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2
BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ
NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk
u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK
PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y
MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4
YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C
PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2
QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D
1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB
kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB
BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE
VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ
BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ
iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw
7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8
c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt
DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX
X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE
BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET
MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG
SIb3DQEJBDEiBCAkfTXQuKSzz2YcDjMAyqd6B7UJdf5pb9xZvB+IW9NfGzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjcxOTMxNTZaMA0GCSqGSIb3
DQEBAQUABIIBAAuX35b/0BiHaRoOKtW166Tp4FCNVGLyVkmEc4dmfPe2R4epv0R0w0rXD9Kl
zdkRFyyiIf0uWoHBOSACFZi0HxPsueqW+/9EXE9JvB4eNoVMjIDJhnylbRqShAS9qqVMrgJe
ijDgEgSJtVEzqZ2Ko+ggT5c/pQZ69MJh4ki/6cbRBm3l1a1I0Z1gvPDNYhW8YXp175aOsBGI
lFeSKgTRQPzpbS9CLN5eCQr7Mib99AFf0AghnSV1px64+gInGPQOsN+Cl1czQKRVISzcwT+6
lp1CsN8dIa2Jynqs2qZiwEh4hVpuRsTPV8yt+aCv/hZnnaIoQfC19Xjfpc5pDvCVNVc=

--B_3484049516_1352091--


From nobody Tue May 27 13:46:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC121A0143 for ; Tue, 27 May 2014 13:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUQTT-gFJWCq for ; Tue, 27 May 2014 13:46:39 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9341A00F4 for ; Tue, 27 May 2014 13:46:38 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4RKkWCV029804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 May 2014 22:46:32 +0200 (MEST)
In-Reply-To: <5384B4F4.9040109@nthpermutation.com>
To: Michael StJohns 
Date: Tue, 27 May 2014 22:46:32 +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: <20140527204632.95AA31AD1D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jl77bvuB6eDs4mg0GMaUazv2wSM
Cc: "tls@ietf.org" 
Subject: Re: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 20:46:41 -0000

Michael StJohns wrote:
> 
> 2) ----------------------------------
> 
> As a specific comment on how the master secret is used:
> 
> The general rule is that the same key shouldn't be used for multiple 
> things.  In this case the master secret is used (ignoring for a moment 
> that the functions are all iterations of the PRF):
> 
>   * with a Key Derivation Function to derive key material
>   * with a MAC function to sign the finished messages
>   * with a keyed pseudo random number generator to derive the IV's.
> 
> By my count that's two too many.  The fact that the KDF and PRNG steps 
> are part of the same process is even more problematic.
> 
> There's literature on this - but an easy reference is section 5.2 of 
> NIST's SP800-57 part 1 rev 3 - 
> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1:
> 
>> 5.2 Key Usage
>> In general, a single key should be used for only one purpose (e.g., 
>> encryption, authentication, key wrapping, random number generation,
>> or digital signatures). There are several reasons for this:


I believe you're misinterpreting the concept of the TLS master secret.

The TLS master secret is *NOT* a key.  It is more like the entropy pool
(internal state) of a DBRG (Deterministic Random Bit Generators).


-Martin


From nobody Tue May 27 14:15:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169B91A026B for ; Tue, 27 May 2014 14:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFAvvDrPpktR for ; Tue, 27 May 2014 14:15:20 -0700 (PDT)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C9E1A06B4 for ; Tue, 27 May 2014 14:15:20 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id rr13so9973468pbb.11 for ; Tue, 27 May 2014 14:15:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rs8EJ7l42GjmqfvG6e8YOHmvEx7hfnVyfHLmiWH6rWc=; b=Q3PkVVCO+c4jmfqWA0RJjSf6gAspQyaUVRJFBgnwSvBTtHMMlcXypm5D44yk8IT9Um eKajfl+9kj61UN41Klk7fQ+BqAkWCxUvmJ9hmXFy7ZErrvJl/1bDEEs8kIwxN4ZtVLLj evpPPAKyMI3Hnzn8QVwGwwrvK/EH8HCYA4EKgd8Q8CN0H9vYqmnRDRedvzd4xb6a27uc PMc+2wfFyQBIcABZcilHIsqsoUZOxwoKXl0gevrCSnhCgBmf1eXkCcNGBhf32ZIgCQde BFiSELWm4qFEKzlMJ/8v6n5RhclVBLfDj34m9lmW3EAIAeUl0BMr4Ale1Ryp7fx1+ziL vBuA==
X-Gm-Message-State: ALoCoQle/kRMyR+De7IrFsktfLIeN9Cr47KuScP9wzlwSbAbL1l/gr7Sm6WGKMgn4TxiIekgNPm1
X-Received: by 10.66.230.193 with SMTP id ta1mr40814318pac.29.1401225317457; Tue, 27 May 2014 14:15:17 -0700 (PDT)
Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id jq6sm24831102pbb.76.2014.05.27.14.15.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 14:15:16 -0700 (PDT)
Message-ID: <5385006C.8080801@nthpermutation.com>
Date: Tue, 27 May 2014 17:15:24 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20140527204632.95AA31AD1D@ld9781.wdf.sap.corp>
In-Reply-To: <20140527204632.95AA31AD1D@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iVsMVk9fLBmgt7LvXzjIDubCrhI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 21:15:22 -0000

On 5/27/2014 4:46 PM, Martin Rex wrote:
> Michael StJohns wrote:
>> 2) ----------------------------------
>>
>> As a specific comment on how the master secret is used:
>>
>> The general rule is that the same key shouldn't be used for multiple
>> things.  In this case the master secret is used (ignoring for a moment
>> that the functions are all iterations of the PRF):
>>
>>    * with a Key Derivation Function to derive key material
>>    * with a MAC function to sign the finished messages
>>    * with a keyed pseudo random number generator to derive the IV's.
>>
>> By my count that's two too many.  The fact that the KDF and PRNG steps
>> are part of the same process is even more problematic.
>>
>> There's literature on this - but an easy reference is section 5.2 of
>> NIST's SP800-57 part 1 rev 3 -
>> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1:
>>
>>> 5.2 Key Usage
>>> In general, a single key should be used for only one purpose (e.g.,
>>> encryption, authentication, key wrapping, random number generation,
>>> or digital signatures). There are several reasons for this:
>
> I believe you're misinterpreting the concept of the TLS master secret.
>
> The TLS master secret is *NOT* a key.  It is more like the entropy pool
> (internal state) of a DBRG (Deterministic Random Bit Generators).



Um.... taken one way you could call any key an entropy pool.  I think 
you're misinterpreting the characteristics of a key.

So, no.

Stealing from the definition of "Cryptographic Key" in SP800-57 part 1 
rev 3:

> A parameter used in conjunction with a cryptographic algorithm that
> determines its operation in such a way that an entity with knowledge of
> the key can reproduce or reverse the operation, while an entity without
> knowledge of the key cannot.

Continuing, the master secret *is* used explicitly as a MAC key 
(finished message) and as a master key for a KDF (key expansion).

Seriously though - no.   Basically if you share it, it's no longer an 
entropy pool, but a key.  And as I've suggested several times before, 
its unclear that the function that generates the IVs needs to to be 
keyed, or do anything except expand the entropy available from 
client_random and server_random to an appropriate length and with a 
particular set of mix-in's.

Mike


>
>
> -Martin


From nobody Tue May 27 14:21:33 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083071A0713 for ; Tue, 27 May 2014 14:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFxtq4VtHM19 for ; Tue, 27 May 2014 14:21:30 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B8A1A0428 for ; Tue, 27 May 2014 14:21:30 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4RLLPeD005792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 May 2014 23:21:25 +0200 (MEST)
In-Reply-To: <5385006C.8080801@nthpermutation.com>
To: Michael StJohns 
Date: Tue, 27 May 2014 23:21:25 +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: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JIIChsNwYR0PTmuHIeAzxxWEuEU
Cc: "tls@ietf.org" 
Subject: Re: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 21:21:32 -0000

Michael StJohns wrote:
> Martin Rex wrote:
>>
>> I believe you're misinterpreting the concept of the TLS master secret.
>>
>> The TLS master secret is *NOT* a key.  It is more like the entropy pool
>> (internal state) of a DBRG (Deterministic Random Bit Generators).
> 
> 
> Um.... taken one way you could call any key an entropy pool.  I think 
> you're misinterpreting the characteristics of a key.
> 
> So, no.
> 
> Stealing from the definition of "Cryptographic Key" in SP800-57 part 1 
> rev 3:
> 
> > A parameter used in conjunction with a cryptographic algorithm that
> > determines its operation in such a way that an entity with knowledge of
> > the key can reproduce or reverse the operation, while an entity without
> > knowledge of the key cannot.
> 
> Continuing, the master secret *is* used explicitly as a MAC key 
> (finished message) and as a master key for a KDF (key expansion).

Unless you're using a NULL encryption ciphersuite, the Finished
messages _are_ encrypted, rather than exchanged in the clear,
and there is a reason why the Finished message is truncated.

For the two communication peers that are involved (TLS client and
TLS server), the master secret is a shared secret.  For any attacker,
the finished messages are not visible (encrypted).


> 
> Seriously though - no.   Basically if you share it, it's no longer an 
> entropy pool, but a key.

There is a necessity to share the master secret with your communication
peer so that both can derive the same new secrets from it.


-Martin


From nobody Tue May 27 14:39:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1321A027D for ; Tue, 27 May 2014 14:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOGnfcdYZGxO for ; Tue, 27 May 2014 14:39:34 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC751A027A for ; Tue, 27 May 2014 14:39:34 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so10422355wes.0 for ; Tue, 27 May 2014 14:39:29 -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:content-type; bh=cwnz0t2EeUk646jwXpl1ZTFF1E54FUzv+CvgPwVwrs0=; b=Y3DViQ+WAdsORioFegO+B/pd2iIQqY3AWGd+w9tTGja7X8OAguP3ao2TkZiQMRM1Kn eiWnGOgFrD+QuYQjux9y21m/cp3DRbLatGL2XX4hBNs53Af9PDKNBt4a0QWy+vo2TkI2 mySP1HEJRt4tXifLNEwd1yAMa8BCzUnXvQaQvMBgoaAaQ4wSbQHX6CSxdif6A6wWFCP8 wPz2jHAR0dZ4VSBPOFBZYeq1LqQlzI0j/GPgdOgZZpTPEs6KEYNHu6IpyrEbdhQGXPdr w5Rkohe5wdAt2VguqXLGviDSvGPVarxOZAorrFHJgJd7Y9ubNTSOXxZoMEOuUUNRc9as T00Q==
MIME-Version: 1.0
X-Received: by 10.194.9.8 with SMTP id v8mr44981735wja.53.1401226769687; Tue, 27 May 2014 14:39:29 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Tue, 27 May 2014 14:39:29 -0700 (PDT)
Date: Tue, 27 May 2014 14:39:29 -0700
Message-ID: 
From: Martin Thomson 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O3SxjrBc_PJD2GWOhwFgIuMQn4k
Subject: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 21:39:36 -0000

I was incapable of doing much real work on a plane last week, so I did this:

https://github.com/tlswg/tls13-spec/pull/41

Here I'm proposing changes that remove renegotiation.  There are some
pieces that are probably separable, and other pieces that might be
controversial, so I'll try to highlight those and then we can discuss
the merits of various approaches.  You know, the regular process.

It's not possible to just remove renegotiation.  After removing
HelloRequest and no_renegotiation, there are some things that need to
be fixed.  The current and pending states for both read and write
direction are integral parts of the spec.

I've proposed a simple mechanism for key refresh.  Basically, either
side sends a ChangeCipherSpec, which triggers the creation of a new
master secret for that direction.  Since CCS was otherwise unused
after removing renegotiation, it can be used to explicitly
indicate/request key refresh.

The proposal mandates a reciprocal CCS to keep the master secret
approximately in sync.  That is, if you receive a CCS, and you haven't
already sent a matching CCS, then you are required to send one.  This
means that an old master secret can be discarded in a bounded amount
of time.

The proposal generates a new master secret from the previous using the
same formula that is used to generate the master from the pre-master
secret.  Obviously, if we change that formula (and it seems likely
that we will) then this should be changed too.

This overloads ChangeCipherSpec, which some might find distasteful,
but I think that it is consistent with it's current use and purpose.

Does this sound like a reasonable approach?


From nobody Tue May 27 15:18:25 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970431A07AE for ; Tue, 27 May 2014 15:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBO_QmBewTOd for ; Tue, 27 May 2014 15:18:20 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2DB1A07A6 for ; Tue, 27 May 2014 15:18:20 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A7C611655B3; Tue, 27 May 2014 22:18:16 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9CB211655AE; Tue, 27 May 2014 22:18:16 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 84CC01E03E; Tue, 27 May 2014 22:18:16 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 27 May 2014 18:18:15 -0400
From: "Salz, Rich" 
To: Martin Thomson , "tls@ietf.org" 
Date: Tue, 27 May 2014 18:18:14 -0400
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: Ac959C+HQ4U/zRPYRR64z8Wcv60H4AABLWUA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/opAFhyJZWY7Y2GzAPP9JFWCas7U
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 22:18:21 -0000

> This overloads ChangeCipherSpec, which some might find distasteful, but I=
 think that it is consistent with it's current use and purpose.

Yeah, I'm not thrilled but it, although I admit it is consistent.

I would rather see something like Yoav (?) proposed via Jabber at the inter=
im meeting:  a "reset but don't close" message.  Either side sends it, the =
other side replies, and at this point all state is thrown away and it's jus=
t as if the client first connected.  It avoids TCP reconnect, perhaps requi=
res more work (but the EDH key should be cached), but it seems much clearne=
r.

	/r$

-- =20
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz


From nobody Tue May 27 15:31:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFCC1A0794 for ; Tue, 27 May 2014 15:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_QEcxQXLqKm for ; Tue, 27 May 2014 15:31:09 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A501A02A2 for ; Tue, 27 May 2014 15:31:09 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id y10so10032037wgg.25 for ; Tue, 27 May 2014 15:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AowrC8X/RpHtLcEgpf5QrpjUOn1H5DrgFYbSPVtc0j0=; b=bTehCaaepuZrpLedGVin8HWXnn6Nshp7XR/ORf7iTq4YCRS6/DtmFzGAsB8byeXCoD 8ndg4acaiz7Wfg/GPX+VgYltazUP90AW+EzUw+WpB/S/ncVmXY0I4GVhPtPiiBnYu6J5 x5FkFg/dqp+/ca+akoPT12QwenTLZAFewmQdxx3eHJvGKy32u6UXckZO59KbZ8Ti9q2Q rWmrSpuXDdt/6noMO9mOT390ZsvMdMbYmrCXedbnSNIvrN/WBYtI5AighERSVS1vSzYH 29unk6zBOFBzaUrbnJ2hDM4bUKO2R9PO0QqWEyiW40CArUiwIxqA7VTzcbhMMzoqWK8d gN4A==
MIME-Version: 1.0
X-Received: by 10.180.97.10 with SMTP id dw10mr42769767wib.38.1401229865210; Tue, 27 May 2014 15:31:05 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Tue, 27 May 2014 15:31:05 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
References:  <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
Date: Tue, 27 May 2014 15:31:05 -0700
Message-ID: 
From: Martin Thomson 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z6NsmHyPOtmtOA_QoNOvyKOSElk
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 May 2014 22:31:11 -0000

On 27 May 2014 15:18, Salz, Rich  wrote:
> I would rather see something like Yoav (?) proposed via Jabber at the int=
erim meeting:  a "reset but don't close" message.  Either side sends it, th=
e other side replies, and at this point all state is thrown away and it's j=
ust as if the client first connected.  It avoids TCP reconnect, perhaps req=
uires more work (but the EDH key should be cached), but it seems much clear=
ner.

If I understand you correctly, and I'm not sure, are you proposing
that we close the TLS connection, but not the TCP connection.  Is the
assumption that we have a 0RTT handshake that is piggybacked
immediately after a close alert so that application data can continue
to flow?

It's certainly clean, in the sense that you get a completely new
security context without some of the overhead.

But it seems a little heavyweight to me.  I'm also concerned about the
performance implications.  A 1RTT handshake would end up with dead air
on the client side if they initiate this, and even with 0RTT, the
server is always penalized if they initiate.  That is, unless we allow
for role inversion, which would make my head hurt.


From nobody Tue May 27 17:06:34 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C851A07D4 for ; Tue, 27 May 2014 17:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ra6LrnXnPiw for ; Tue, 27 May 2014 17:06:29 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240F21A02ED for ; Tue, 27 May 2014 17:06:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=231; q=dns/txt; s=iport; t=1401235586; x=1402445186; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zRMAeMs96V2vOS1JqwMu7vfJFctOD07aa9VX1uu4Z0o=; b=Avd51Xmm+jX8AqIVtH/zkrTpt3AZlYxzqa1wg7maMdT5LkAxo+vj39Kc 0TMF3KQcjizc1QKcGPOfBdmYfCUuj1pqbnewf4b0CTBbHQHUswZ2SEHHd f6IiuBZBEKU267Yb3ttBBa8Dg9TzFpH/zUz8FwSuzB+PezMgcGD6ymrV4 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFADcohVOtJA2I/2dsb2JhbABZgwdSGT+NBbUWgRMWdIIsOlEBPkInBByIOQ2hVbNlF5IEgRUEmXOTJ4M4gi8
X-IronPort-AV: E=Sophos;i="4.98,923,1392163200"; d="scan'208";a="47764628"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 28 May 2014 00:06:19 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4S06J8H029258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 May 2014 00:06:19 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 27 May 2014 19:06:19 -0500
From: "Joseph Salowey (jsalowey)" 
To: "" 
Thread-Topic: Minutes from the Spring 2014 TLS Interim
Thread-Index: AQHPegimqgV9uITvMUGGAb4sYYq9gg==
Date: Wed, 28 May 2014 00:06:19 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.248.116]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/otIEWbhzYCNMA8Wp3_xsiTkOyvo
Subject: [TLS] Minutes from the Spring 2014 TLS Interim
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 00:06:31 -0000

The meeting minutes from the TLS Interim meeting have been uploaded to http=
://www.ietf.org/proceedings/interim/2014/05/15/tls/minutes/minutes-interim-=
2014-tls-1

Let me know if you have any corrections.

Thanks,

Joe=


From nobody Tue May 27 17:13:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF771A081F for ; Tue, 27 May 2014 17:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9sXb35Fgys7 for ; Tue, 27 May 2014 17:13:20 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426161A07D4 for ; Tue, 27 May 2014 17:13:20 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id lf10so9996916pab.34 for ; Tue, 27 May 2014 17:13:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=g8E8GY3arnZrRaXsAfumKN1vGvByS6KeAwKVKU1//14=; b=eD9HjgmrwWFHSu6n0OSs07MH9xJ7EL4/tc8ikQLXqekxRkcMekMEFe/OQzI9juNobi ez/W6bEcisoOKnDkRsHNQzrzDwfggoNm3nhKgdDwC9c5vv1izS+u4BIcUZuLH2tpKz1M PDDtDEDOMBkpC3b9sgcm43zkqcAoGHtF2q54A4meKg8aAJ8tAcrdA8pqRO2j4OMXIncD UCtMskTOmvFMEWL6jA6rgkg3s3T60huKofh4D3bJs+PamuZ1kD3oId+O+EDaeX69StqP HX086AeRTHSBfYwSMtTvsDDbown8VLsXafyy5ewTVwvLyYz+2bPq4orOb86ucbcxmsPN 34Kw==
X-Gm-Message-State: ALoCoQmhp8dpfyagg7ldjB0hvf+ZnCa1r+/YJB48U1hdC6rNss8oX4jZ13Ei2tmOZlkDIsYbSKGb
X-Received: by 10.68.106.130 with SMTP id gu2mr40482713pbb.59.1401235997040; Tue, 27 May 2014 17:13:17 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id xg4sm25234060pbb.47.2014.05.27.17.13.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 17:13:16 -0700 (PDT)
Message-ID: <53852A1B.6000808@amacapital.net>
Date: Tue, 27 May 2014 17:13:15 -0700
From: Andy Lutomirski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Salz, Rich" ,  Martin Thomson , "tls@ietf.org" 
References:  <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AxIgxbjdaqxc9J9ArOe1XIcOStg
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 00:13:21 -0000

On 05/27/2014 03:18 PM, Salz, Rich wrote:
>> This overloads ChangeCipherSpec, which some might find distasteful, but I think that it is consistent with it's current use and purpose.
> 
> Yeah, I'm not thrilled but it, although I admit it is consistent.
> 
> I would rather see something like Yoav (?) proposed via Jabber at the interim meeting:  a "reset but don't close" message.  Either side sends it, the other side replies, and at this point all state is thrown away and it's just as if the client first connected.  It avoids TCP reconnect, perhaps requires more work (but the EDH key should be cached), but it seems much clearner.

I suspect that, without a lot of API care, this will reintroduce the
original renegotiation attack: client sends a prefix, says "reset but
don't close", and starts forwarding ciphertext from a different client.

--Andy


From nobody Tue May 27 17:44:43 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12371A0834 for ; Tue, 27 May 2014 17:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhv6Pv2zpcqU for ; Tue, 27 May 2014 17:44:15 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463BB1A0827 for ; Tue, 27 May 2014 17:44:15 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s4S0i8kf014131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 May 2014 02:44:09 +0200 (MEST)
In-Reply-To: 
To: Martin Thomson 
Date: Wed, 28 May 2014 02:44:08 +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: <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vly_BIJsX-MOIdJrJzNvmj7-Maw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 00:44:21 -0000

Martin Thomson wrote:
> 
> Here I'm proposing changes that remove renegotiation.
>
> It's not possible to just remove renegotiation.
> After removing HelloRequest and no_renegotiation, there are some
> things that need to be fixed.  The current and pending states for
> both read and write direction are integral parts of the spec.

I haven't looked at the details, but this sound terrible.

The beauty of the original TLS renegotiation is that it doesn't
really exist.  For the state machine, it is a regular full TLS
handshake, for the record layer, it is just a replacement of
the current state with the next state upon CCS.

The only problem with TLS renogitation, if there ever was one,
is with the flawed assumptions of the application about what
characteristics it provides (i.e that another successful TLS
handshake could be abused to provide an OTP-style authentication
of all data previously received over that TLS channel.


Renegotiation could be combined with an abbreviated TLS handshake
to provide fast rekeying of the traffic protection keys (not creating
a new entry in the TLS session cache), and renegotiation could be
combined with a full TLS handshake, creating a new, self-contained
entry in the TLS session cache that can be resumed on different
connections with an abbreviated TLS handshake.


Conceptually, the TLS session cache is readonly after an entry
is created, and that is GOOD, i.e. full TLS handshakes create new,
distict session cache entries, and abbreviated TLS handshakes resume
existing session cache entries and *NEVER* modify them.


The original architecture allows for a very simple and robust
TLS protocol state machine for the TLS handshake (allows!=implies,
you can implement arbitrarily complicated TLS state machines if you
so desire, just look at some of the OpenSource implementations).



> 
> The proposal generates a new master secret from the previous using the
> same formula that is used to generate the master from the pre-master
> secret.  Obviously, if we change that formula (and it seems likely
> that we will) then this should be changed too.

It sounds like quite a lot more stuff will have to be carried over
from the previous session state to the next.  Now what does this mean
for the abbreviated TLS handshake?  When, where and how do you issue
a new session ID, or how does this change affect abbreviated
TLS handshakes happening on independent parallel connections? 


-Martin


From nobody Tue May 27 18:11:20 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB611A084E for ; Tue, 27 May 2014 18:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTYS79paWim5 for ; Tue, 27 May 2014 18:11:02 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326701A0857 for ; Tue, 27 May 2014 18:10:45 -0700 (PDT)
Received: by mail-yk0-f177.google.com with SMTP id 19so7755478ykq.8 for ; Tue, 27 May 2014 18:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WzdbEyAdPHNt/DoEXrVAIh9LioYxNJT/FWup3Hg7uLs=; b=vkqxL81VNDLZJz+3Eg2+dfbABRAmf+WQ8LO7W0LiSd4GW12LA4nSH0X4m+DWgY2Im/ A4PLkzX7Y5Z8I0Y5xyMECn/PxXNR+dQ4fJ/OKpqlw6j/5E3wsuQNSektvMGl8pOP0lfJ mVzIWbp/F1HyBC2/bYc7vcQ4lAVyQ69uc8XadDMC8w2Z94fKLWkHLA3p2K9flUGzVYR3 Ke2eII4MywbHs4ZS0injOCRnx3DD+sWjZPG6tWstFpZOWlVEty42nkk4pbw7WUpjRiXD gaSl8cBHNLzgqd4om5omdD5OakslYq9fPX8CtRclvRTQf2jpXHbFrr9yZScN95bJgQp5 qDWg==
MIME-Version: 1.0
X-Received: by 10.236.126.9 with SMTP id a9mr16736129yhi.83.1401239441369; Tue, 27 May 2014 18:10:41 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Tue, 27 May 2014 18:10:41 -0700 (PDT)
Received: by 10.170.39.136 with HTTP; Tue, 27 May 2014 18:10:41 -0700 (PDT)
In-Reply-To: <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
Date: Tue, 27 May 2014 18:10:41 -0700
Message-ID: 
From: Watson Ladd 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=20cf3011dacb25ee7e04fa6b7bd8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RDhwbCjBOQrHkhSaqpDEyukkHQ8
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 01:11:06 -0000

--20cf3011dacb25ee7e04fa6b7bd8
Content-Type: text/plain; charset=UTF-8

On May 27, 2014 5:44 PM, "Martin Rex"  wrote:
>
> Martin Thomson wrote:
> >
> > Here I'm proposing changes that remove renegotiation.
> >
> > It's not possible to just remove renegotiation.
> > After removing HelloRequest and no_renegotiation, there are some
> > things that need to be fixed.  The current and pending states for
> > both read and write direction are integral parts of the spec.
>
> I haven't looked at the details, but this sound terrible.
>
> The beauty of the original TLS renegotiation is that it doesn't
> really exist.  For the state machine, it is a regular full TLS
> handshake, for the record layer, it is just a replacement of
> the current state with the next state upon CCS.
>
> The only problem with TLS renogitation, if there ever was one,
> is with the flawed assumptions of the application about what
> characteristics it provides (i.e that another successful TLS
> handshake could be abused to provide an OTP-style authentication
> of all data previously received over that TLS channel.

The security considerations never mentioned the issue.  In fact you were
one of the codiscoverers, years after the spec was authored. Do you
consider it a nonissue?

One can argue that TLS never has flaws, just assumptions that it is
"secure" which aren't true. Or one could say that we have to provide
semantics people expect.

>
>
> Renegotiation could be combined with an abbreviated TLS handshake
> to provide fast rekeying of the traffic protection keys (not creating
> a new entry in the TLS session cache), and renegotiation could be
> combined with a full TLS handshake, creating a new, self-contained
> entry in the TLS session cache that can be resumed on different
> connections with an abbreviated TLS handshake.
>
>
> Conceptually, the TLS session cache is readonly after an entry
> is created, and that is GOOD, i.e. full TLS handshakes create new,
> distict session cache entries, and abbreviated TLS handshakes resume
> existing session cache entries and *NEVER* modify them.
>
>
> The original architecture allows for a very simple and robust
> TLS protocol state machine for the TLS handshake (allows!=implies,
> you can implement arbitrarily complicated TLS state machines if you
> so desire, just look at some of the OpenSource implementations).
>
>
>
> >
> > The proposal generates a new master secret from the previous using the
> > same formula that is used to generate the master from the pre-master
> > secret.  Obviously, if we change that formula (and it seems likely
> > that we will) then this should be changed too.
>
> It sounds like quite a lot more stuff will have to be carried over
> from the previous session state to the next.  Now what does this mean
> for the abbreviated TLS handshake?  When, where and how do you issue
> a new session ID, or how does this change affect abbreviated
> TLS handshakes happening on independent parallel connections?

Does resuming the same connection twice make sense? Now that you mention
the issue I see how it can happen. But we only need to refresh the keys
used for data, not the PMS.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--20cf3011dacb25ee7e04fa6b7bd8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On May 27, 2014 5:44 PM, "Martin Rex" <mrex@sap.com> wrote:

>

> Martin Thomson wrote:

> >

> > Here I'm proposing changes that remove renegotiation.

> >

> > It's not possible to just remove renegotiation.

> > After removing HelloRequest and no_renegotiation, there are some<=
br>
> > things that need to be fixed. =C2=A0The current and pending state=
s for

> > both read and write direction are integral parts of the spec.

>

> I haven't looked at the details, but this sound terrible.

>

> The beauty of the original TLS renegotiation is that it doesn't
> really exist. =C2=A0For the state machine, it is a regular full TLS
> handshake, for the record layer, it is just a replacement of

> the current state with the next state upon CCS.

>

> The only problem with TLS renogitation, if there ever was one,

> is with the flawed assumptions of the application about what

> characteristics it provides (i.e that another successful TLS

> handshake could be abused to provide an OTP-style authentication

> of all data previously received over that TLS channel.


The security considerations never mentioned the issue.=C2=A0=
 In fact you were one of the codiscoverers, years after the spec was author=
ed. Do you consider it a nonissue? 


One can argue that TLS never has flaws, just assumptions tha=
t it is "secure" which aren't true. Or one could say that we =
have to provide semantics people expect.


>

>

> Renegotiation could be combined with an abbreviated TLS handshake

> to provide fast rekeying of the traffic protection keys (not creating<=
br>
> a new entry in the TLS session cache), and renegotiation could be

> combined with a full TLS handshake, creating a new, self-contained

> entry in the TLS session cache that can be resumed on different

> connections with an abbreviated TLS handshake.

>

>

> Conceptually, the TLS session cache is readonly after an entry

> is created, and that is GOOD, i.e. full TLS handshakes create new,

> distict session cache entries, and abbreviated TLS handshakes resume
> existing session cache entries and *NEVER* modify them.

>

>

> The original architecture allows for a very simple and robust

> TLS protocol state machine for the TLS handshake (allows!=3Dimplies,
> you can implement arbitrarily complicated TLS state machines if you
> so desire, just look at some of the OpenSource implementations).

>

>

>

> >

> > The proposal generates a new master secret from the previous usin=
g the

> > same formula that is used to generate the master from the pre-mas=
ter

> > secret. =C2=A0Obviously, if we change that formula (and it seems =
likely

> > that we will) then this should be changed too.

>

> It sounds like quite a lot more stuff will have to be carried over

> from the previous session state to the next. =C2=A0Now what does this =
mean

> for the abbreviated TLS handshake? =C2=A0When, where and how do you is=
sue

> a new session ID, or how does this change affect abbreviated

> TLS handshakes happening on independent parallel connections?


Does resuming the same connection twice make sense? Now that=
 you mention the issue I see how it can happen. But we only need to refresh=
 the keys used for data, not the PMS.


>

>

> -Martin

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls




--20cf3011dacb25ee7e04fa6b7bd8--


From nobody Tue May 27 21:00:07 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69461A0303 for ; Tue, 27 May 2014 21:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh2dFlOyM2KC for ; Tue, 27 May 2014 21:00:06 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id F10CB1A02F8 for ; Tue, 27 May 2014 21:00:05 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6B0444815A; Wed, 28 May 2014 04:00:02 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 5F42248156; Wed, 28 May 2014 04:00:02 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 458D69803E; Wed, 28 May 2014 04:00:02 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 28 May 2014 00:00:01 -0400
From: "Salz, Rich" 
To: Martin Thomson 
Date: Wed, 28 May 2014 00:00:00 -0400
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: Ac95+1xSxj8WdbcCSFKkgl16YvSxeAALc20g
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C0CE5@USMBX1.msg.corp.akamai.com>
References:  <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K6NcON07naBxJGVAcm6g4UEFKV4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 04:00:06 -0000

WWVzLCB5b3UgdW5kZXJzdGFuZCBpdC4gIFllcywgdGhlIHRyYWRlLW9mZnMgYXJlIGxpa2UgeW91
IGRlc2NyaWJlLiBJIGhhcHBlbiB0byB0aGluayBpdCdzIGNsZWFuZXIgYW5kIGxlc3MgbGlrZWx5
IHRvIGhhdmUgc2VjdXJpdHkgaXNzdWVzLCBidXQgd2UgY2VydGFpbmx5IG5lZWQgbW9yZSBkaXNj
dXNzaW9ucy4gDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRl
Y2hub2xvZ2llcywgQ2FtYnJpZGdlLCBNQQ0KSU06IHJzYWx6QGphYmJlci5tZTsgVHdpdHRlcjog
UmljaFNhbHoNCg0K


From nobody Tue May 27 22:47:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95BF1A0358 for ; Tue, 27 May 2014 22:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz2tNBVqFu7I for ; Tue, 27 May 2014 22:47:53 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96701A033E for ; Tue, 27 May 2014 22:47:52 -0700 (PDT)
Received: by mail-qg0-f45.google.com with SMTP id z60so16207722qgd.18 for ; Tue, 27 May 2014 22:47:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h/1c2bdH2iHOjYgrEwlXFRFA8kyU/gdiBuDGnerB7Io=; b=OPQdztiO5NM+tEidLq7hTPJE94tLmH++XQYHXPh42wGTUnn1Qx/QJzMUPb4VkgZFVP tv2SAJNiHRtnCLASbbCT3r33eNJbMQ4odEpqXIbjS0g6uTYaZo9Xrmwuh4arModYsR/7 EI4CqcaPwsb8d/kHEs/FVxqKcZWxQs1TjYf+dh/hFdWhq/ZKSX4MishH3lxMjajsBkzz 3SyJzYPaQJTxsIn+eDvRuP8UzeW3kmdY1vzKv8DD4OA4TZnAKe2jZSFysRQb44mVU2YF mSEwk6otrCDB/itTyd1BD5OBXL+hynAVTcZbNY0LL8hLmseT3iA5ZnR45wqUmWiwhSLV yFLA==
X-Gm-Message-State: ALoCoQkrJP4q3ZLCNclITdZehe4mYn1rC9KgP4ufuKHLdKGGo/3zZLapTG2Ce0YTIwFelQ2tFqUm
MIME-Version: 1.0
X-Received: by 10.140.46.53 with SMTP id j50mr47496559qga.27.1401256068839; Tue, 27 May 2014 22:47:48 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Tue, 27 May 2014 22:47:48 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 27 May 2014 22:47:48 -0700
Message-ID: 
From: Brian Smith 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a113a7e5c3917d204fa6f5afb
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q4V7HvDeVBq9OnPq7dw_7CFuMe0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 05:47:53 -0000

--001a113a7e5c3917d204fa6f5afb
Content-Type: text/plain; charset=UTF-8

On Tue, May 27, 2014 at 2:39 PM, Martin Thomson wrote:

> It's not possible to just remove renegotiation.
>

Why not? What is the motivation for keeping any form of renegotiation, even
rekeying? It isn't clear from the public mailing list discussions what is
motivating the rekeying feature. (Perhaps I overlooked something; if so, a
link to the past decision on this would be appreciated.)


> After removing
> HelloRequest and no_renegotiation, there are some things that need to
> be fixed.  The current and pending states for both read and write
> direction are integral parts of the spec.
>

I don't think documenting/managing those states would be integral at all if
we didn't need to support rekeying.

Cheers,
Brian

--001a113a7e5c3917d204fa6f5afb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Tue, May 27, 2014 at 2:39 PM, Martin Thomson <martin.thomson@gma=
il.com> wrote:


It's not possible to just remove renegotiation.



Why not? What is the motivation for keeping any form of=
 renegotiation, even rekeying? It isn't clear from the public mailing l=
ist discussions what is motivating the rekeying feature. (Perhaps I overloo=
ked something; if so, a link to the past decision on this would be apprecia=
ted.)


=C2=A0
After removing

HelloRequest and no_renegotiation, there are some things that need to

be fixed. =C2=A0The current and pending states for both read and write

direction are integral parts of the spec.

I don't think documenting/managing those st=
ates would be integral at all if we didn't need to support rekeying.

Cheers,
Brian


--001a113a7e5c3917d204fa6f5afb--


From nobody Wed May 28 00:02:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A984E1A0377 for ; Wed, 28 May 2014 00:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaDTBFcpbSvv for ; Wed, 28 May 2014 00:02:10 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1F1A0019 for ; Wed, 28 May 2014 00:02:10 -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 s4S7252O009061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 May 2014 03:02:05 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4S72385012862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 03:02:04 -0400
Message-ID: <1401260523.2336.7.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos 
To: Martin Thomson 
Date: Wed, 28 May 2014 09:02:03 +0200
In-Reply-To: 
References: 
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X7gk7pQgCgaqtzflyROpWXuX-Ow
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 07:02:12 -0000

On Tue, 2014-05-27 at 14:39 -0700, Martin Thomson wrote:
> I was incapable of doing much real work on a plane last week, so I did this:
> 
> https://github.com/tlswg/tls13-spec/pull/41
> 
> Here I'm proposing changes that remove renegotiation.  There are some
> pieces that are probably separable, and other pieces that might be
> controversial, so I'll try to highlight those and then we can discuss
> the merits of various approaches.  You know, the regular process.

What problem does this removal solves? There is no motivation written in
your text.

regards,
Nikos




From nobody Wed May 28 03:00:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB301A089F for ; Wed, 28 May 2014 03:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSjRgGUlFg-O for ; Wed, 28 May 2014 03:00:13 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A937E1A08B1 for ; Wed, 28 May 2014 03:00:07 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q59so11054498wes.35 for ; Wed, 28 May 2014 03:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=J6E1JL1U/8ZPDp8bTBuRyL2gZvaYBbQ3QSV6XueSDtI=; b=W5n9lJTlGluX9OhhnFC8vNLTSgTTWprTEQzitRnkth654jp+INtOc5HM1QJ2AkdtTa c6bw3oQrcF+ZYq+DPS3dmuX86ePrZ3R0SrAt12O5zNIEVQkWydKjDHTGBlGfgXKZyCuS QFozbHnICPrNtKTCpowjX/Arvwo9q5ga+S12njNSRnt9MLKI8ZY9MYxosv6QYu1i8yyy KPpdMtbFBQojYqgsHv+j3wW05MgNwIF/Clb6UdeOCZnDTApszEFP8HCP9nhxZZUZ5IRD BQP4f3l3IumbxLK8wOCmMczhBBk1oigQWfoKWk06cEd8AiAD8JKb6oam1B7N920dhYbr v1pQ==
X-Received: by 10.194.24.36 with SMTP id r4mr19969115wjf.39.1401271203108; Wed, 28 May 2014 03:00:03 -0700 (PDT)
Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ln3sm41998553wjc.8.2014.05.28.03.00.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 03:00:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_73EBAA94-CC0D-451A-B075-5ADD14CCDCE5"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir 
In-Reply-To: 
Date: Wed, 28 May 2014 13:00:00 +0300
Message-Id: <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com>
References:  
To: Brian Smith 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2PO2yRvtYeAalZqi9bVDtbE7l7U
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 10:00:15 -0000

--Apple-Mail=_73EBAA94-CC0D-451A-B075-5ADD14CCDCE5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On May 28, 2014, at 8:47 AM, Brian Smith  wrote:

>=20
> On Tue, May 27, 2014 at 2:39 PM, Martin Thomson =
 wrote:
> It's not possible to just remove renegotiation.
>=20
> Why not? What is the motivation for keeping any form of renegotiation, =
even rekeying? It isn't clear from the public mailing list discussions =
what is motivating the rekeying feature. (Perhaps I overlooked =
something; if so, a link to the past decision on this would be =
appreciated.)
> =20

Why not?  Because people are using it to accomplish things, and you =
can=92t just pull it away without giving them some other way of doing =
what they=92re doing, otherwise you get =93TLS 1.3 is not suitable for =
long-lived connections=94 or =93TLS 1.3 is not suitable for mutual =
authentication=94.

With that in mind, in discussions on this list and at the interim =
meeting two uses for renegotiation were mentioned:

1. Client Authentication. For various UI reasons, web applications don=92t=
 want to send a certificate request on the landing page. They want the =
certificate authentication in response to a request for a protected =
resource, one that requires an authenticated client. This is not =
something that Google, Facebook or Tumblr use, but it=92s much more =
common in SSL VPNs, corporate portals, and some banking web sites.  =
Martin has a couple of drafts for making this happen in a combination of =
HTTP authentication method (=93go away and come back with a =
certificate=94) and a TLS extension (=93I have a certificate. Please =
send a CertReq=94).

2. Connections that carry so much traffic and last so very long that you =
really need to rekey. This was discussed at the meeting, partially on =
Jabber ([1]). It=92s not that common for the web, but I=92m assured that =
XMPP connections sometimes last basically forever, so they need =
rekeying. My proposal there (at 19:40) was for this use case. Martin is =
right that it adds =93dead air=94, but all these use cases are not that =
delay sensitive, and I think it=92s worth it to get the simplified state =
machine.

Yoav

[1] http://www.ietf.org/jabber/logs/tls/2014-05-16.html around 19:24=

--Apple-Mail=_73EBAA94-CC0D-451A-B075-5ADD14CCDCE5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On May 28, 2014, at 8:47 AM, Brian =
Smith <brian@briansmith.org> =
wrote:


On Tue, May 27, 2014 at 2:39 PM, Martin Thomson =
<martin.thomson@gmail.com> wrote:


It's not possible to just remove =
renegotiation.



Why not? What is the motivation for keeping any form =
of renegotiation, even rekeying? It isn't clear from the public mailing =
list discussions what is motivating the rekeying feature. (Perhaps I =
overlooked something; if so, a link to the past decision on this would =
be appreciated.)


 

Why =
not?  Because people are using it to accomplish things, and you =
can=92t just pull it away without giving them some other way of doing =
what they=92re doing, otherwise you get =93TLS 1.3 is not suitable for =
long-lived connections=94 or =93TLS 1.3 is not suitable for mutual =
authentication=94.

With that in mind, in =
discussions on this list and at the interim meeting two uses for =
renegotiation were mentioned:

1. Client =
Authentication. For various UI reasons, web applications don=92t want to =
send a certificate request on the landing page. They want the =
certificate authentication in response to a request for a protected =
resource, one that requires an authenticated client. This is not =
something that Google, Facebook or Tumblr use, but it=92s much more =
common in SSL VPNs, corporate portals, and some banking web sites. =
 Martin has a couple of drafts for making this happen in a =
combination of HTTP authentication method (=93go away and come back with =
a certificate=94) and a TLS extension (=93I have a certificate. Please =
send a CertReq=94).

2. Connections that carry =
so much traffic and last so very long that you really need to rekey. =
This was discussed at the meeting, partially on Jabber ([1]). It=92s not =
that common for the web, but I=92m assured that XMPP connections =
sometimes last basically forever, so they need rekeying. My proposal =
there (at 19:40) was for this use case. Martin is right that it adds =
=93dead air=94, but all these use cases are not that delay sensitive, =
and I think it=92s worth it to get the simplified state =
machine.

Yoav

=

--Apple-Mail=_73EBAA94-CC0D-451A-B075-5ADD14CCDCE5--


From nobody Wed May 28 03:05:46 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8131A08B3 for ; Wed, 28 May 2014 03:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgP-WerbG_sG for ; Wed, 28 May 2014 03:05:43 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264841A08B4 for ; Wed, 28 May 2014 03:05:42 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t60so11132134wes.27 for ; Wed, 28 May 2014 03:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DUJ36uKuxT/NjszGecOAxBsPfbpj8KU12ef9M/xJFfU=; b=qznagBsv74FY33T/EkGtP4C8L5IYkQfZo8CDIFIAWiDvhO50JAt/lnbpQhX+JB8/Do 9h1Vvjy01S8c5eO56R1HgLL72ePhrxAR1c28FS4u1ctXy4ZXdxZ+p/6+LM2wfBu0v0HA ZaDtuwwtdMoPDH9XM1GINixnnyjUnz8qNgILTtYySIa/NrXy8femtXSHSE7OyNHJnuyH uNsY+eVI2yov9HJIO06PqxtsTIQEkro3iUzFbZxJPtnowyggPZaMiL1y01OcFzx5fdBT MJ2tlHrk4eydkOUJtT9Z5On53/CCpgE3Yry+rDX7g2AY50Rbuhqm7iH9HRBO6SH1Ok9R ib1w==
X-Received: by 10.194.249.134 with SMTP id yu6mr42253753wjc.86.1401271538568;  Wed, 28 May 2014 03:05:38 -0700 (PDT)
Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id bj2sm15621517wib.3.2014.05.28.03.05.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 03:05:38 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir 
In-Reply-To: <53852A1B.6000808@amacapital.net>
Date: Wed, 28 May 2014 13:05:35 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <955C8E0E-81DC-4301-ABBA-F763D1223C37@gmail.com>
References:  <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com> <53852A1B.6000808@amacapital.net>
To: Andy Lutomirski 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pLVN8kWUHJgh0M8LiGtQ0L6456g
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 10:05:45 -0000

On May 28, 2014, at 3:13 AM, Andy Lutomirski  =
wrote:

> On 05/27/2014 03:18 PM, Salz, Rich wrote:
>>> This overloads ChangeCipherSpec, which some might find distasteful, =
but I think that it is consistent with it's current use and purpose.
>>=20
>> Yeah, I'm not thrilled but it, although I admit it is consistent.
>>=20
>> I would rather see something like Yoav (?) proposed via Jabber at the =
interim meeting:  a "reset but don't close" message.  Either side sends =
it, the other side replies, and at this point all state is thrown away =
and it's just as if the client first connected.  It avoids TCP =
reconnect, perhaps requires more work (but the EDH key should be =
cached), but it seems much clearner.
>=20
> I suspect that, without a lot of API care, this will reintroduce the
> original renegotiation attack: client sends a prefix, says "reset but
> don't close", and starts forwarding ciphertext from a different =
client.

Definitely, so we=92d need a same or similar indication to prevent =
abuse. I tend to think that a binary indication of =93initial contact=94 =
would be enough (as normal clients will always be =93initial contact=94 =
and a ClientHello with =93initial contact=94 should never appear after =
StopTLS), but I could be wrong.

Yoav


From nobody Wed May 28 09:39:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791601A0164 for ; Wed, 28 May 2014 09:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOXDbNbdMyyW for ; Wed, 28 May 2014 09:38:54 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C588C1A0450 for ; Wed, 28 May 2014 09:38:53 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id cc10so4004161wib.16 for ; Wed, 28 May 2014 09:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jmayhroh/CPr0i1Ird7nmUcox7nUkwQLNlItBOiA7+A=; b=vbIadrdJJ7bMLJLr/nounjuFFvGN3XwsRZpA7JjhlyzdUBfk6Z9Ah4G3P39v0JeuOt 9hqsU5g8yYBu/4in/rFcVAB2Ehtod0d8rT7CuorQTzqZ4eV0GwRo+40v6IfIXmwhLHRe vduK0ZOsZLla+mi9akUT4TOGnF74JHh/Lj5rki0A99c2ZDh/olCOM1QYyxjNfCshsqwM loxk0IcECQ6WHGpv38ylslUsOyAJtxyWwbNWLpIkiImVg+liyQToUbQi2j2eWP3ZSQue HovJDDA8ip/XuqGTtmJMBSMyZSAKd5w8zfYw0a6wwqksqwMTuaOfexyyN6sCLka6zL0Q faKA==
MIME-Version: 1.0
X-Received: by 10.180.72.243 with SMTP id g19mr50844411wiv.44.1401295127275; Wed, 28 May 2014 09:38:47 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 09:38:47 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 28 May 2014 09:38:47 -0700
Message-ID: 
From: Martin Thomson 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8PKQb-n8HGm3JLvKqz_4x_6MpRI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 16:38:59 -0000

On 27 May 2014 22:47, Brian Smith  wrote:
>> It's not possible to just remove renegotiation.
>
>
> Why not? What is the motivation for keeping any form of renegotiation, even
> rekeying? It isn't clear from the public mailing list discussions what is
> motivating the rekeying feature. (Perhaps I overlooked something; if so, a
> link to the past decision on this would be appreciated.)

That statement was merely referring to the fact that there are other
considerations that removing renegotiation exposes:

AES-GCM (for example) can't be used with the same key indefinitely.
2^32 records is the limit apparently.  We have reports of services
that use the same connection for up to months with high volumes of
traffic.  Over that period, the sequence number might roll over, even
if the keys are still good.  Rekeying allows for those uses.

It also provides a measure of forward security in that old keys can be
thrown away.  A break of a server only allows the attacker to gain the
plaintext of a connection back to the last rekeying event.

Then there's the use of renego for HTTP, but we've discussed that
already and the tentative plan is to push on HTTPbis to come up with a
solution that doesn't depend on TLS.  Failing that, or in the event
that we discover other users of spontaneous client authentication, we
will build something into TLS.  That will probably be something
lightweight that doesn't cause the sorts of issues Martin (R) doesn't
think are worth worrying about.

>> The current and pending states for both read and write
>> direction are integral parts of the spec.
>
>I don't think documenting/managing those states would be integral at all if we didn't need to support rekeying.

That's right.  That's a presentation consideration, as alluded to
above.  As much as possible, I tried to make them non-integral in my
proposed text.


From nobody Wed May 28 09:46:58 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C61A0A08 for ; Wed, 28 May 2014 09:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkYFQ2FbBUWP for ; Wed, 28 May 2014 09:46:56 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6651A09E2 for ; Wed, 28 May 2014 09:46:56 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id k48so11734163wev.17 for ; Wed, 28 May 2014 09:46: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zktIvKZoF4aTe2TIT4mf3/7GxZSPT/yXRnxI6d+Udas=; b=Q9P07RpWG1A0P3sBPV/ss8WO2evLqF8O3zmoS1dXBpC684T+x6J11tG5YKKUntQ9J8 Xw8XEO7pQgsI5nOA4R6BRYckpjs4PfDKwsP/VfwXvQPjY1tSIFqrJXfKvKkqhVI0F8Cv fz6V1IfXV07I0AAvB7TOpiagnMThrsDQUjHqkWLZF/9m4QSH0Dawnc6qD5zTHs1AygBS FTvjnkDRVGGQb9mH7hDWAKeR0ntqvnu9R95ckT6k0RtxU48XzfmYJry/gF85jyvE5CTl umkaDsiIfheKvidoQ72VEW8PSEGZe72zwjQfgrObh7Yac8BViEHLtM7RWLuZlfOykGDS RmaA==
MIME-Version: 1.0
X-Received: by 10.180.36.241 with SMTP id t17mr2616711wij.38.1401295609511; Wed, 28 May 2014 09:46:49 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 09:46:49 -0700 (PDT)
In-Reply-To: <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com>
References:   <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com>
Date: Wed, 28 May 2014 09:46:49 -0700
Message-ID: 
From: Martin Thomson 
To: Yoav Nir , "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vWlU25TbQc2dolKBfsISEL7kJqI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 16:46:57 -0000

On 28 May 2014 03:00, Yoav Nir  wrote:
> 2. Connections that carry so much traffic and last so very long that you
> really need to rekey. This was discussed at the meeting, partially on Jab=
ber
> ([1]). It=E2=80=99s not that common for the web, but I=E2=80=99m assured =
that XMPP
> connections sometimes last basically forever, so they need rekeying. My
> proposal there (at 19:40) was for this use case. Martin is right that it
> adds =E2=80=9Cdead air=E2=80=9D, but all these use cases are not that del=
ay sensitive, and I
> think it=E2=80=99s worth it to get the simplified state machine.

I think that we might be able to mitigate the dead air problem.  At
least if the client initiates the action.

My concerns with this approach are with the obvious tension between
the obvious goal and the goals of the application/API.

The establishment of an entirely new context is only truly useful if
it is treated as such.  But the goal of applications in this context
is to continue to operate seamlessly.  Many of the concerns arising
from renegotiation arise from the way that applications are almost
willfully ignorant of the transition in states.

As Martin (R) observes, renegotiation is fairly precisely defined.  If
you strictly respect it, it can be safe...in theory.  It's just that
it's rarely afforded that respect.


From nobody Wed May 28 10:02:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B371A04A6 for ; Wed, 28 May 2014 10:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXW6y-yonqwU for ; Wed, 28 May 2014 10:02:09 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CFF1A6ED9 for ; Wed, 28 May 2014 10:02:05 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id bs8so4221687wib.12 for ; Wed, 28 May 2014 10:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OC8XxAZdXxnTYHGcx9VUcp7VoDyx5QuUvCgBYM9BfCM=; b=SUu2E+nFZKeWe08C6LXJqOVjIykphRmpATp3uOFz1KJCOzLoJwZwSk+sQzXD/YEpSQ u+LE9wbPj7VrZ0MHqq+Yjl0p8NaXMomIiftKGhn6QZbRhVOfENuCnjzAAhfXbPw2V+4O tVUPw2mCQkREuRnY0TFIk91e2lorQO3X5fEbXiJJ7M0SdOMXsvZCRXGbNEMEVvEdJhzH aney+qhxOIvVM3FxZp4nr/9P2B9/RgxPpWNzFDoq5Ot0rH4RA7oLJ+u+tv6g1UNnse9q jwrMh8X3PfjcyBPnDNZ9khBvjcaGtasnCQtGhUDUylozFBoah0KdtX84LUgS2ecKXOFN 18Xw==
MIME-Version: 1.0
X-Received: by 10.180.96.6 with SMTP id do6mr2713573wib.44.1401296520800; Wed, 28 May 2014 10:02:00 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 10:02:00 -0700 (PDT)
In-Reply-To: <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
Date: Wed, 28 May 2014 10:02:00 -0700
Message-ID: 
From: Martin Thomson 
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BbRfEWhZvoldfff5oDlYVtgzEeI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:02:10 -0000

On 27 May 2014 17:44, Martin Rex  wrote:
> Conceptually, the TLS session cache is readonly after an entry
> is created, and that is GOOD, i.e. full TLS handshakes create new,
> distict session cache entries, and abbreviated TLS handshakes resume
> existing session cache entries and *NEVER* modify them.

That's a good point.  Something that I missed.  A resumption handshake
would have to include an epoch from the previous session.  That number
would need to be incremented with each update of the master secret.

Alternatively, and I think preferably, we could allow (or require)
servers to send the NewSessionTicket message when they update the
master secret, so that there isn't a master secret lying around
anywhere.

Of course, if you want to argue for unmodifiable state, then maybe you
can provide stronger justification than that.


From nobody Wed May 28 10:24:40 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CDF1A0A80 for ; Wed, 28 May 2014 10:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQQy37sOPBKK for ; Wed, 28 May 2014 10:24:36 -0700 (PDT)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA7A1A0A79 for ; Wed, 28 May 2014 10:24:34 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id w62so11516606wes.2 for ; Wed, 28 May 2014 10:24:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gFrNT6v+C8z8n6e9cSho136rRu/CcSd975z2MOySBEo=; b=WS4YTMR9TAS3WQ4fpMQ2H5rI33z03l1Q8m9GcyqUQi+oHf3E/Qjiz2oceAlu/hZGU6 WLdYkUx2IR53xIWtMMyfrHW9ioO7VH5luRoSjTOCLd562rdZAJH3Cf2Kt4Y/6/szXgY7 5vHWXs0PC5BLoBct46U7dDtZMiE9S9ak+tWuKsif6OzGLGFouGON9GGLSVdzk1DPv6px oKVeRTDmSPV7htiNpnivT8GCbO9xjhoFm2qownO6206wJesXPIFvCeYGfckMPbo2YElq 3RPjowcQTq4s+HPmxKjHVBs4AyMR9u/Nc8fPYAXj23nqgPXbZA+OTTs9df01yAgaPTY2 sVQw==
X-Gm-Message-State: ALoCoQmD7taSpEUC+s+pRBoD6VurEXHnRQ301ZeDI236RccPvJ2LuKCq9P3wAVcrFOQeMvYe8A74
X-Received: by 10.194.62.176 with SMTP id z16mr1434830wjr.76.1401297869415; Wed, 28 May 2014 10:24:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Wed, 28 May 2014 10:23:49 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:7931:db29:b29d:2f29]
In-Reply-To: 
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp> 
From: Eric Rescorla 
Date: Wed, 28 May 2014 10:23:49 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=047d7ba979c2bb426b04fa791580
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RNSRxNUjytpT2GIHu-52xSt4HVw
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:24:38 -0000

--047d7ba979c2bb426b04fa791580
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 10:02 AM, Martin Thomson
wrote:

> On 27 May 2014 17:44, Martin Rex  wrote:
> > Conceptually, the TLS session cache is readonly after an entry
> > is created, and that is GOOD, i.e. full TLS handshakes create new,
> > distict session cache entries, and abbreviated TLS handshakes resume
> > existing session cache entries and *NEVER* modify them.
>
> That's a good point.  Something that I missed.  A resumption handshake
> would have to include an epoch from the previous session.  That number
> would need to be incremented with each update of the master secret.
>

That's one option. The other option is just to flush your session cache. To
the best of my knowledge, systems generally either have a lot of connection
setups (which makes session caching attractive) or long-lived connections
(where you would want to change keys) but usually not both.

-Ekr

--047d7ba979c2bb426b04fa791580
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, May 28, 2014 at 10:02 AM, Martin Thomson =
<martin.th=
omson@gmail.com> wrote:



On 27 May 2014 17:44, Martin=
 Rex <mrex@sap.com> wrote:

> Conceptually, the TLS session cache is readonly after an entry

> is created, and that is GOOD, i.e. full TLS handshakes create new,

> distict session cache entries, and abbreviated TLS handshakes resume
> existing session cache entries and *NEVER* modify them.




That's a good point. =C2=A0Something that I missed. =C2=A0A resum=
ption handshake

would have to include an epoch from the previous session. =C2=A0That number=


would need to be incremented with each update of the master secret.

That's one option. The other option is jus=
t to flush your session cache. To
the best of my knowledge, syste=
ms generally either have a lot of connection



setups (which makes session caching attractive) or long-lived connecti=
ons
(where you would want to change keys) but usually not both.

-Ekr



--047d7ba979c2bb426b04fa791580--


From nobody Wed May 28 10:26:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050B71A04A2 for ; Wed, 28 May 2014 10:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLcuYFntWRDZ for ; Wed, 28 May 2014 10:26:09 -0700 (PDT)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365201A01C3 for ; Wed, 28 May 2014 10:26:09 -0700 (PDT)
Received: by mail-qg0-f46.google.com with SMTP id q108so18266649qgd.19 for ; Wed, 28 May 2014 10:26:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hsux7Va3t6KZiSd1/hXsDaXUkB3KJKLW3sKxQaPrAUk=; b=T9E7IYkmijlpKBCaligazXqJ5u/yyZwlhSdo4Yvn3N/23YKsBu2jZPKH46RrhGGk7b N3NL/Z2m+fh5037raiRiaaPOQvkE4pIF/Orf3AQshjZFO7YpaJyFLbrIf5dHBZmrTFUt EDkpKlDXIcxVH+STmDEOn/x7boHu8gchHOHHTHOr3wXPH/zG1c2bHiYwVQ+tGszBSP6u o/ELcrazZZjMj4B2nmGZgcpPg3lqwAxSwMsYu2m9oXtps/4WD8I6rquP2VVvUbIx00aG i+ZVhuDhTOuz858idgHDw5/f4nyk5Jir+KAftzXlFUeqdmi9PITZxtkWSeLMirFpWD+b P2vg==
X-Gm-Message-State: ALoCoQkOu37846Fd6vpOay+pMxjlRoZOg3eiePF7YUnOIrURajvvshLsn47p71Rdqz0w7RoBLm1d
MIME-Version: 1.0
X-Received: by 10.224.36.141 with SMTP id t13mr1295527qad.75.1401297965228; Wed, 28 May 2014 10:26:05 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Wed, 28 May 2014 10:26:05 -0700 (PDT)
In-Reply-To: <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>
Date: Wed, 28 May 2014 10:26:05 -0700
Message-ID: 
From: Brian Smith 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=089e0149d0e471370c04fa791bc0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yljLtSoSeWukNqiFTXczQfQDI80
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:26:10 -0000

--089e0149d0e471370c04fa791bc0
Content-Type: text/plain; charset=UTF-8

On Tue, May 27, 2014 at 5:44 PM, Martin Rex  wrote:

> Conceptually, the TLS session cache is readonly after an entry
> is created, and that is GOOD, i.e. full TLS handshakes create new,
> distict session cache entries, and abbreviated TLS handshakes resume
> existing session cache entries and *NEVER* modify them.
>

That is not true. During session resumption, the server can send a new
session ticket for the existing session and the client has the option of
adding the new ticket to the session (and removing the old ticket).

Also often timestamps (e.g. for LRU replacement bookkeeping) and/or
counters (e.g. for cache hit rate statistics) in a session are updated
during resumption, though these are "just" implementation issues.

Cheers,
Brian

--089e0149d0e471370c04fa791bc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, May 27, 2014 at 5:44 PM, Martin Rex <mrex@sap.com> wrote:
=


Conceptually, the TLS session cache is readonly after an entry

is created, and that is GOOD, i.e. full TLS handshakes create new,

distict session cache entries, and abbreviated TLS handshakes resume

existing session cache entries and *NEVER* modify them.

That is not true. During session resumption, th=
e server can send a new session ticket for the existing session and the cli=
ent has the option of adding the new ticket to the session (and removing th=
e old ticket).


Also often timestamps (e.g. for LRU replacement bookkeeping) and/or cou=
nters (e.g. for cache hit rate statistics) in a session are updated during =
resumption, though these are "just" implementation issues.


Cheers,
Brian


--089e0149d0e471370c04fa791bc0--


From nobody Wed May 28 10:35:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8491A0417 for ; Wed, 28 May 2014 10:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YZ0ZuMFaB5A for ; Wed, 28 May 2014 10:35:28 -0700 (PDT)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E911A0A2B for ; Wed, 28 May 2014 10:35:28 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id i50so18820869qgf.3 for ; Wed, 28 May 2014 10:35:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B9pixl/MwEq/qpox+yY2RcKNi1djhOAiTa0r1l1rXzQ=; b=QB+D4XgZfZTFU3Zu7poM25vJk6Dyv1G5tXDHXF6Mf9y+SQChiHiXZzOUTnbJhoNwyK /Lz800DSkYJ8BjFFaWYLvJZY6VbtEueSEGlKLBhiebQ30Ve0Abd76XvzZArbkA5YUptX Gg0bKysrhcqWpxp+GS2JlBRer0bAyMYqZbWVSoEHVLn4E39PsifxKtI43X7qweaCe1SG ubBIoL+BwtvX46saQRInXFcl4eOVoQ54uicCS3IGWszye5TM+qznswxhGQLc91nmCt8l 64t8+wDhLLsv8FaMVuQhPlx8kJFezutdqN4uX0pmNo2IwEGmtPgCUQ0izUJkQReeme4u mPqQ==
X-Gm-Message-State: ALoCoQl+3rWWg5I28dKR7eZvvWGDwCYAPrv1J8Ab/31glr8pPIObg20ZzOcwaH0VVRrLran362FS
MIME-Version: 1.0
X-Received: by 10.140.46.53 with SMTP id j50mr1475206qga.27.1401298524226; Wed, 28 May 2014 10:35:24 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Wed, 28 May 2014 10:35:24 -0700 (PDT)
In-Reply-To: <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com>
References:   <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com>
Date: Wed, 28 May 2014 10:35:24 -0700
Message-ID: 
From: Brian Smith 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=001a113a7e5cc2dcd704fa793cc1
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qg4NQVHOwcFTOulgoW03zkCDsRg
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:35:30 -0000

--001a113a7e5cc2dcd704fa793cc1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 28, 2014 at 3:00 AM, Yoav Nir  wrote:

> On May 28, 2014, at 8:47 AM, Brian Smith  wrote:
>
> On Tue, May 27, 2014 at 2:39 PM, Martin Thomson wrote:
>
>> It's not possible to just remove renegotiation.
>>
>
> Why not? What is the motivation for keeping any form of renegotiation,
> even rekeying? It isn't clear from the public mailing list discussions wh=
at
> is motivating the rekeying feature. (Perhaps I overlooked something; if s=
o,
> a link to the past decision on this would be appreciated.)
>
> 1. Client Authentication.
>



> Martin has a couple of drafts for making this happen in a combination of
> HTTP authentication method (=E2=80=9Cgo away and come back with a certifi=
cate=E2=80=9D) and
> a TLS extension (=E2=80=9CI have a certificate. Please send a CertReq=E2=
=80=9D).
>

FWIW, I think the idea that Martin is pursuing is the right approach to
this issue.


> 2. Connections that carry so much traffic and last so very long that you
> really need to rekey. This was discussed at the meeting, partially on
> Jabber ([1]). It=E2=80=99s not that common for the web, but I=E2=80=99m a=
ssured that XMPP
> connections sometimes last basically forever, so they need rekeying. My
> proposal there (at 19:40) was for this use case. Martin is right that it
> adds =E2=80=9Cdead air=E2=80=9D, but all these use cases are not that del=
ay sensitive, and
> I think it=E2=80=99s worth it to get the simplified state machine.
>

As you say, these applications are not delay sensitive. Also, these
applications have to be able to recover from long-lived connections being
broken. So, for these applications, why isn't it acceptable to just close
the connection/session and open a new one?

I think it would be helpful to see some examples of real-world applications
(preferably, but not exclusively open source) that actually do currently
use renegotiation to rekey a long-lived connection.

Assuming rekeying would be an optional feature like renegotiation is, would
web browsers and/or common web servers actually implement rekeying? It
would be very tempting to leave it out to reduce the chance of
implementation mistakes if it were optional.

Cheers,
Brian

--001a113a7e5cc2dcd704fa793cc1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, May 28, 2014 at 3:00 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:


On May 28, 2014, at 8:47 AM, Brian Smith <brian@briansmith.org> =
wrote:


On Tue, May 27, 2014 at 2:39 PM, Martin Thomson <martin.thomson@gmail.com> wrote:



It's not =
possible to just remove renegotiation.



Why not? What is the motivation for keeping any form of=
 renegotiation, even rekeying? It isn't clear from the public mailing l=
ist discussions what is motivating the rekeying feature. (Perhaps I overloo=
ked something; if so, a link to the past decision on this would be apprecia=
ted.) 


1. Client Authentication.<=
/div>

<snip> 


Martin has a couple of drafts for makin=
g this happen in a combination of HTTP authentication method (=E2=80=9Cgo a=
way and come back with a certificate=E2=80=9D) and a TLS extension (=E2=80=
=9CI have a certificate. Please send a CertReq=E2=80=9D).



FWIW, I think the idea that Martin is purs=
uing is the right approach to this issue.
=C2=A0


2. Connections that car=
ry so much traffic and last so very long that you really need to rekey. Thi=
s was discussed at the meeting, partially on Jabber ([1]). It=E2=80=99s not=
 that common for the web, but I=E2=80=99m assured that XMPP connections som=
etimes last basically forever, so they need rekeying. My proposal there (at=
 19:40) was for this use case. Martin is right that it adds =E2=80=9Cdead a=
ir=E2=80=9D, but all these use cases are not that delay sensitive, and I th=
ink it=E2=80=99s worth it to get the simplified state machine.



As you say, these applications are n=
ot delay sensitive. Also, these applications have to be able to recover fro=
m long-lived connections being broken. So, for these applications, why isn&=
#39;t it acceptable to just close the connection/session and open a new one=
?


I think it would be helpful to see some examples of real-wor=
ld applications (preferably, but not exclusively open source) that actually=
 do currently use renegotiation to rekey a long-lived connection.



Assuming rekeying would be an optional feature like renegotiatio=
n is, would web browsers and/or common web servers actually implement rekey=
ing? It would be very tempting to leave it out to reduce the chance of impl=
ementation mistakes if it were optional.


Cheers,
Brian



--001a113a7e5cc2dcd704fa793cc1--


From nobody Wed May 28 10:43:03 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7F51A0A26 for ; Wed, 28 May 2014 10:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kOOIXv40v6g for ; Wed, 28 May 2014 10:42:55 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455C31A0494 for ; Wed, 28 May 2014 10:42:55 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so11800618wes.28 for ; Wed, 28 May 2014 10:42:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6a51K3B4V/BAMeYr7YVqpL/Jh7EW7K3x6937JwOpRjk=; b=BPY+BX0Cpszle/zWqZWycTnQz/B9KZQl+9w/Ji6abqzS2BF/9orPM53rb0TutrD3gd BnqpmGWBYJkcA25M1QbksJS+P6IAfMpKuE/7MfMLPrSAzDMZqQiI4lJ2He0nY79lHQ8L 8gYVFJcBziub4pX0YG94aNEVaj43YM+OJAXp5QHbL31FpidlfcpyNAQGDE2SFBBYBvxK e9A3SWEbwu8nzTkJbGwC8vrB+n01Tns1ORwSemekCP6PvHBZhWCp/k79kQo0MmllQyyl zc9ZbhZchIlDKYx54lzv8ehamYxeJN5JlQ2idBuQY9mssq231Y/y0KDcr6OF+rWKNGji Ijpg==
MIME-Version: 1.0
X-Received: by 10.180.72.243 with SMTP id g19mr51379273wiv.44.1401298969917; Wed, 28 May 2014 10:42:49 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 10:42:49 -0700 (PDT)
In-Reply-To: 
References:   <28421B15-8E06-4E86-AE5D-38D994ABBD45@gmail.com> 
Date: Wed, 28 May 2014 10:42:49 -0700
Message-ID: 
From: Martin Thomson 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JXEvle1SiXLOywdfk9xD_uXUtAg
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:42:59 -0000

On 28 May 2014 10:35, Brian Smith  wrote:
>> 2. Connections that carry so much traffic and last so very long that you
>> really need to rekey. This was discussed at the meeting, partially on Ja=
bber
>> ([1]). It=E2=80=99s not that common for the web, but I=E2=80=99m assured=
 that XMPP
>> connections sometimes last basically forever, so they need rekeying. My
>> proposal there (at 19:40) was for this use case. Martin is right that it
>> adds =E2=80=9Cdead air=E2=80=9D, but all these use cases are not that de=
lay sensitive, and I
>> think it=E2=80=99s worth it to get the simplified state machine.
>
> As you say, these applications are not delay sensitive.

The specific example we've been given was XMPP.  That is somewhat
delay sensitive.  These high volume channels can't really afford to
waste round trips.  Now, a make-before-break arrangement might be
enough.  I can ask an expert.


From nobody Wed May 28 10:47:03 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318B51A6EE4 for ; Wed, 28 May 2014 10:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JumuU-74hfiC for ; Wed, 28 May 2014 10:46:53 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5FE1A6EF0 for ; Wed, 28 May 2014 10:46:45 -0700 (PDT)
Received: from [10.70.10.60] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id ECA73F986; Wed, 28 May 2014 13:46:39 -0400 (EDT)
Message-ID: <538620F3.6060605@fifthhorseman.net>
Date: Wed, 28 May 2014 13:46:27 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Eric Rescorla ,  Martin Thomson 
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>  
In-Reply-To: 
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X1EKi6pfgsWa1bO7tO48gdRCe7oks1bIP"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A6IY728tgR8IUvf3jX-9DQYc6C0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:46:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--X1EKi6pfgsWa1bO7tO48gdRCe7oks1bIP
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 05/28/2014 01:23 PM, Eric Rescorla wrote:
> On Wed, May 28, 2014 at 10:02 AM, Martin Thomson wrote:
>=20
>> On 27 May 2014 17:44, Martin Rex  wrote:
>>> Conceptually, the TLS session cache is readonly after an entry
>>> is created, and that is GOOD, i.e. full TLS handshakes create new,
>>> distict session cache entries, and abbreviated TLS handshakes resume
>>> existing session cache entries and *NEVER* modify them.
>>
>> That's a good point.  Something that I missed.  A resumption handshake=

>> would have to include an epoch from the previous session.  That number=

>> would need to be incremented with each update of the master secret.
>=20
> That's one option. The other option is just to flush your session cache=
=2E

I'm not sure i understand this argument properly, but:

> To
> the best of my knowledge, systems generally either have a lot of connec=
tion
> setups (which makes session caching attractive) or long-lived connectio=
ns
> (where you would want to change keys) but usually not both.

Doesn't the classic XMPP server case have both?  there are a lot of c2s
connection setups which could benefit from session caching, and several
long-lived connections for the s2s connections which could benefit from
being able to re-key.

	--dkg


--X1EKi6pfgsWa1bO7tO48gdRCe7oks1bIP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJThiDzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcQUUP/3WtxCxIwZ2+9m5M1WdKobht
YoifKRikQsNOIIfV9WK8YljTqikdItdUIyCqtSUBZg2w2zeEf8kWgC/B4uRy+Wp7
4qkcaRlcEmDOZ4DU6hTCMEmo+5tlufagjVKb6Bu33e28W/d/tZtKvFxdErYkQQ0j
SXQMdFLgP25AiyYyQd1BLXB3bv/0QxcfyafJQpCzI1bhJf8Tl9FIsHmw5zCaDQPc
Oq1xn8wYbUHoxxhoc/El1dpHW1GvVAt876fz3kAaXXk3PrhuwanxYuZBuDNo2TaO
AvEofZIawOU4TLSomwexdvAg1sve9TXq770xmD2Sx1pZqOI2eC0ahsVb5QYdJMj8
h/UMZ0zvbkC2OYmaUcLsB2mjsiMi7kBftYQ7PRxvE9LEzeZD05Fd/ubZcLkWEDhr
2TVgRxRRf9gamrqEizwx+WWFtI79pZvrR/8CTCyqJri5qDjwQG4a114U/s3RcJBi
6ypClOxh2b+ZIBhcTc8YswZ64ImfRma1hRpau9TCLPvmC6m5lM492I/p3ROECuDu
vZtIn7kZfhxGZ0uJwQ5XICUV1tqmS94qjoa7VxVa2qY3ox/MshQouyDKAY0zM5Ht
MrDjwaZf8XoKS2Tmek7B33ommfISmED+Rq9/aE9BpHvMGOFtGC6Pf4hYikVQCcpa
GMfJVMbFaIvcWx8snt3L
=H5WD
-----END PGP SIGNATURE-----

--X1EKi6pfgsWa1bO7tO48gdRCe7oks1bIP--


From nobody Wed May 28 10:50:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3741A6EED for ; Wed, 28 May 2014 10:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXH2wUbiTYDl for ; Wed, 28 May 2014 10:50:19 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602C21A6EDB for ; Wed, 28 May 2014 10:50:19 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id q58so2820097wes.25 for ; Wed, 28 May 2014 10:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=07Ef/rec6PLIbmZfFhrfOe4CmYCMwHm2ffjfH/YPngc=; b=yCUfp+8XMKGRbRXhGWFjcvj1lbIajV7Qt0w73wk/zZLBt/vGFiou1nGKzCPIz7Lht+ NdiLF8hzGzRBxb16vrqBufV5X7WG1pPTywRdNz655rYwdftF1ittdoOMaB5Z0sZLemV4 PgfPCEZZJjULlWRsXMM0KATO06aHH/u8icKoJVN41HGwfrFOVlowTuj3rPiNzRmoaRdD J4Ku1a/DrwH+YnvQK1axdixB0Q2enlo30YPjp4Qx/Dh9nlt2Z9g8GrSdenqCGO25AUSp vhFQVyYLQORSQvu5Zz1uLXly56NMfzXtl2/FU7NQ6R0xUxq3mqgk1sHJ1v8EggagONh6 t+SA==
MIME-Version: 1.0
X-Received: by 10.195.18.8 with SMTP id gi8mr1403449wjd.75.1401299414794; Wed, 28 May 2014 10:50:14 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 10:50:14 -0700 (PDT)
In-Reply-To: <538620F3.6060605@fifthhorseman.net>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>   <538620F3.6060605@fifthhorseman.net>
Date: Wed, 28 May 2014 10:50:14 -0700
Message-ID: 
From: Martin Thomson 
To: Daniel Kahn Gillmor 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zgdBWZoNLBajChz7xlfVV51g1KY
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 17:50:21 -0000

On 28 May 2014 10:46, Daniel Kahn Gillmor  wrote:
>> To
>> the best of my knowledge, systems generally either have a lot of connection
>> setups (which makes session caching attractive) or long-lived connections
>> (where you would want to change keys) but usually not both.
>
> Doesn't the classic XMPP server case have both?  there are a lot of c2s
> connection setups which could benefit from session caching, and several
> long-lived connections for the s2s connections which could benefit from
> being able to re-key.

It sounded OK to me.  If you live long enough to require a rekey, then
throw away your session ticket.


From nobody Wed May 28 11:47:44 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9031A212D for ; Wed, 28 May 2014 11:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6flBHUMMhZH5 for ; Wed, 28 May 2014 11:47:41 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAC51A0B80 for ; Wed, 28 May 2014 11:47:41 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 090AD1C2151 for ; Wed, 28 May 2014 20:47:36 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id CE96B1FE0150; Wed, 28 May 2014 20:47:35 +0200 (CEST)
Date: Wed, 28 May 2014 20:47:35 +0200
From: Kurt Roeckx 
To: tls@ietf.org
Message-ID: <20140528184735.GA20602@roeckx.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vYB8-pHI4YamBxIB1CqDjPYiUkQ
Subject: [TLS] OCSP must staple
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 18:47:43 -0000

Hi,

It seems there is a draft to have OCSP must staple
(draft-hallambaker-muststaple-00).  Does anybody know what the
status of that is?  I've tried to contact the author but didn't
get any reply.

Is this something we want adopt?


Kurt


From nobody Wed May 28 12:00:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB441A6F51 for ; Wed, 28 May 2014 12:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.054
X-Spam-Level: 
X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qg__fXl3ZAj for ; Wed, 28 May 2014 12:00:33 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1831A6F41 for ; Wed, 28 May 2014 12:00:33 -0700 (PDT)
Received: from JROWLEYL2 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 5CBF37FA3D6; Wed, 28 May 2014 13:00:29 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1401303629; bh=HBy8+3u+zPlat5j2MUB3cIv3rD8HnFmoYk/trBkIVxw=; h=From:To:References:In-Reply-To:Subject:Date; b=DtItq+rjXRglgmSwS4IrQ9AMIXaG5gqG5gTRtiFU6u4aQ4YzVByXTxhBC7WG3flRt NeqebaySvEumHkAl9U1gIEdv5sQ3ssF/wytd0JjS2Up5ikOyLLZzB2dLXQxbELfKzG rK+Z4YjinTzsR7u9P6dWbjIjJe8Z8k6sIX6BnfT0=
From: "Jeremy Rowley" 
To: "'Kurt Roeckx'" , 
References: <20140528184735.GA20602@roeckx.be>
In-Reply-To: <20140528184735.GA20602@roeckx.be>
Date: Wed, 28 May 2014 13:00:28 -0600
Message-ID: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFsdq/DppDfU/GgDQi/wJFPER5LaZwcYIrA
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MqXlbBYZ4ZDfRM0-NjcJI6n0IYM
Subject: Re: [TLS] OCSP must staple
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 19:00:36 -0000

We do.  I believe PHB was waiting for an OID assigned by IANA for must
staple.   I'm not sure the request was ever submitted, but I'll follow up
and make sure this moves forward.

Jeremy

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Kurt Roeckx
Sent: Wednesday, May 28, 2014 12:48 PM
To: tls@ietf.org
Subject: [TLS] OCSP must staple

Hi,

It seems there is a draft to have OCSP must staple
(draft-hallambaker-muststaple-00).  Does anybody know what the status of
that is?  I've tried to contact the author but didn't get any reply.

Is this something we want adopt?


Kurt

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Wed May 28 12:55:18 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506441A068B for ; Wed, 28 May 2014 12:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7HfJJctx9L4 for ; Wed, 28 May 2014 12:55:15 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C3D1A0386 for ; Wed, 28 May 2014 12:55:15 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rp16so11723455pbb.20 for ; Wed, 28 May 2014 12:55:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jrf1pn0eZe3CW0c7b/rhQEP+ysJn6kBTm4eYnXtcHqs=; b=ih9g/B3ZcGd40lApfS2HAQzxm3b1AVdRdArYnl+fqBiAJ1UviSc8nmgXZYDwpB9cKZ /pw29RfwOW8v3h7bfcataLULdz/WEWSt6as5DUYKskYEwyOSokNPd28SDsXZIIb1E8Ua P7pZxp2Q7ynCxHs8R/Ix7jWUfj5xwHyeQl429oKSiCD6rtbYTH9qX/8WJp/titlFxEuA Zy4MA9SeuhYAUZNjaTQ6o9j5qo1AbkPiJOL1XdyeX9GuVGSK+txoc8Wmg+94W58//ahl 3QlMgQcrW4tWBXrBgbzXB9cEzOlycG8BjabF/DaM6kanj3jDD5cQRtcHT+paOealY5WR pDLw==
X-Gm-Message-State: ALoCoQmvhKlW97yUkrgVmHFVgMgtX5FDUvOLgJ1gAv25Ylt/iNoYAvWw3OZL+EY0pf949vgPlvV3
X-Received: by 10.68.138.227 with SMTP id qt3mr2631719pbb.6.1401306911573; Wed, 28 May 2014 12:55:11 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id ec2sm29737801pbc.63.2014.05.28.12.55.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 12:55:10 -0700 (PDT)
Message-ID: <53863F1D.3060707@amacapital.net>
Date: Wed, 28 May 2014 12:55:09 -0700
From: Andy Lutomirski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Martin Thomson , mrex@sap.com
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HkVAytuNaVLRQT9o75jX39T9hlo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 19:55:16 -0000

On 05/28/2014 10:02 AM, Martin Thomson wrote:
> On 27 May 2014 17:44, Martin Rex  wrote:
>> Conceptually, the TLS session cache is readonly after an entry
>> is created, and that is GOOD, i.e. full TLS handshakes create new,
>> distict session cache entries, and abbreviated TLS handshakes resume
>> existing session cache entries and *NEVER* modify them.
> 
> That's a good point.  Something that I missed.  A resumption handshake
> would have to include an epoch from the previous session.  That number
> would need to be incremented with each update of the master secret.

Rather than mucking with the master secret, can't we rearrange the key
hierarchy a bit:

Separately derive master_secret and temporary_secret from
premaster_secret.  Use master_secret as it's currently used for
resumption, but use temporary_secret for encryption and MAC.  When it's
time to rekey, roll over the temporary_secret but leave the
master_secret alone.

Getting resumption right might be a little tricky here: unless a new DH
exchange happens on resumption, the new temporary_secret will have to be
derived from master_secret.

This gets another benefit for free: a compromise of the session cache or
the ticket key doesn't compromise old non-resumed connections.


--Andy


From nobody Wed May 28 12:59:39 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9404F1A068F for ; Wed, 28 May 2014 12:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZBV_Epwx2EE for ; Wed, 28 May 2014 12:59:36 -0700 (PDT)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA801A068B for ; Wed, 28 May 2014 12:59:36 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id j5so19485700qga.14 for ; Wed, 28 May 2014 12:59:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GEDcZzAAn0pDwlGhzBisSwz9g8Abdj7TD4lZ3Pk8lFo=; b=mjT5F74+Gg9lMyreQj/LRTcW15l2ALlAJ82CrDheKOyLv9kwIFtsPKyM+cyujy9MTM 4bV19hGHUTzyDlGyiNKGb6KmArZEcPSCwPheped3cUOIIs4/69aYSzwCwUWS5htfGOq+ gcwAOCcJQUjeAMm1VHjQi0sVF2YF1/2nNzX6QLEwmEQEjowvdt9TxQH14k3a36fjQgGd gTK5bqVv0S5mQ9MU2+eOYnpCGg8SEf37GgxZWaJ50Kl1A3/d4aHbjjlL+5xb8KUpkYZ5 /KvbMYkNkyO6k66nNgCXi1i76EMPeQ4liFYyPHB9cJBq9JeibCcOkueRydltWgUUgwF/ Mrbg==
X-Gm-Message-State: ALoCoQli/5GVfFJ1GPcyD19YI/m07FMrHusXWer0yu54xGoYzeeQ3IfOBce0ciZHOOkQeaV+9mrM
MIME-Version: 1.0
X-Received: by 10.229.70.196 with SMTP id e4mr3128867qcj.16.1401307172435; Wed, 28 May 2014 12:59:32 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Wed, 28 May 2014 12:59:32 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 28 May 2014 12:59:32 -0700
Message-ID: 
From: Brian Smith 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a1133bb583c0e4704fa7b40ff
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vZzc0wsaRNQO3fel-_kWjraPCc8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 19:59:37 -0000

--001a1133bb583c0e4704fa7b40ff
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 9:38 AM, Martin Thomson wrote:

> On 27 May 2014 22:47, Brian Smith  wrote:
> >> It's not possible to just remove renegotiation.
> >
> >
> > Why not? What is the motivation for keeping any form of renegotiation,
> even
> > rekeying? It isn't clear from the public mailing list discussions what is
> > motivating the rekeying feature. (Perhaps I overlooked something; if so,
> a
> > link to the past decision on this would be appreciated.)
>
> That statement was merely referring to the fact that there are other
> considerations that removing renegotiation exposes:
>
> AES-GCM (for example) can't be used with the same key indefinitely.
> 2^32 records is the limit apparently.  We have reports of services
> that use the same connection for up to months with high volumes of
> traffic.  Over that period, the sequence number might roll over, even
> if the keys are still good.  Rekeying allows for those uses.
>

Understood. However, as I implied in my other responses today, I don't
think TLS is the place to support that use case. It is enough for the TLS
implementation to be only responsible for ensuring that we don't use a key
beyond safe limits for its usage. How the application recovers from that
limit being reached can be delegated to the application. The advantage with
this is that only the applications that need to deal with this problem are
impacted by it.


> It also provides a measure of forward security in that old keys can be
> thrown away.  A break of a server only allows the attacker to gain the
> plaintext of a connection back to the last rekeying event.
>

I understand the idea is that both sides could throw away the old master
secret right away and then nobody would be able to decrypt the traffic
protected by that old master secret. However, the "master secret
advancement" mechanism you proposed is calculated using only the old master
secret plus public nonces, which raises some risk of related-key attacks.
As Martin Rex was saying, the advantage of TLS-1.2-style renegotiation is
that the new master secret is clearly (could be made to be) completely
unrelated to the the previous master secret so that related key attacks
aren't (could be made to not be) an issue.

Thus, while a simpler rekeying mechanism definitely makes the protocol
simpler, we'd be trading a useful cryptographic property for that
simplicity. And, most implementations that would support it would actually
become more complicated by having to support both TLS < 1.3 renegotiation
AND TLS 1.3 rekeying.

Consequently, I still think we should keep trying to get rid of
renegotiation without adding anything new in TLS to replace it.

Cheers,
Brian

--001a1133bb583c0e4704fa7b40ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, May 28, 2014 at 9:38 AM, Martin Thomson <martin.thomson@gmail=
.com> wrote:


On 27 May 2014 22:47, Brian =
Smith <brian@briansmith.org&=
gt; wrote:


>> It's not possible to just remove renegotiation.

>

>

> Why not? What is the motivation for keeping any form of renegotiation,=
 even

> rekeying? It isn't clear from the public mailing list discussions =
what is

> motivating the rekeying feature. (Perhaps I overlooked something; if s=
o, a

> link to the past decision on this would be appreciated.)




That statement was merely referring to the fact that there are other<=
br>
considerations that removing renegotiation exposes:



AES-GCM (for example) can't be used with the same key indefinitely.

2^32 records is the limit apparently. =C2=A0We have reports of services

that use the same connection for up to months with high volumes of

traffic. =C2=A0Over that period, the sequence number might roll over, even<=
br>
if the keys are still good. =C2=A0Rekeying allows for those uses.

Understood. However, as I implied in my other re=
sponses today, I don't think TLS is the place to support that use case.=
 It is enough for the TLS implementation to be only responsible for ensurin=
g that we don't use a key beyond safe limits for its usage. How the app=
lication recovers from that limit being reached can be delegated to the app=
lication. The advantage with this is that only the applications that need t=
o deal with this problem are impacted by it.

=C2=A0


It also provides a measure of forward security in that old keys can be

thrown away. =C2=A0A break of a server only allows the attacker to gain the=


plaintext of a connection back to the last rekeying event.
=


I understand the idea is that both sides could throw away the old =
master=20
secret right away and then nobody would be able to decrypt the traffic=20
protected by that old master secret. However, the "master secret advan=
cement" mechanism you proposed is calculated using only the old master=
 secret plus public nonces, which raises some risk of related-key attacks. =
As Martin Rex was saying, the advantage of TLS-1.2-style renegotiation is t=
hat the new master secret is clearly (could be made to be) completely unrel=
ated to the the previous master secret so that related key attacks aren'=
;t (could be made to not be) an issue.


Thus, while a simpler rekeying mechanism definitely makes the protocol =
simpler, we'd be trading a useful cryptographic property for that simpl=
icity. And, most implementations that would support it would actually becom=
e more complicated by having to support both TLS < 1.3 renegotiation AND=
 TLS 1.3 rekeying.


Consequently, I still think we should keep trying to get rid=
 of renegotiation without adding anything new in TLS to replace it.

=

Cheers,
Brian


--001a1133bb583c0e4704fa7b40ff--


From nobody Wed May 28 13:05:55 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75011A0051 for ; Wed, 28 May 2014 13:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OSS2148m2Bu for ; Wed, 28 May 2014 13:05:50 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4981A0383 for ; Wed, 28 May 2014 13:05:49 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B704D1655A8; Wed, 28 May 2014 20:05:45 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id AC25E1655A5; Wed, 28 May 2014 20:05:45 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 7D9FB1E03D; Wed, 28 May 2014 20:05:45 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 28 May 2014 16:05:45 -0400
From: "Salz, Rich" 
To: Brian Smith , Martin Thomson 
Date: Wed, 28 May 2014 16:05:44 -0400
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: Ac96r16l7yk8kWpGRv2qW7XAq1vidAAAHuww
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141CUSMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/92KNdfieJw0Encz7K8EDjD8v364
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:05:52 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141CUSMBX1msgcorp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

w5ggIFRoZSBhZHZhbnRhZ2Ugd2l0aCB0aGlzIGlzIHRoYXQgb25seSB0aGUgYXBwbGljYXRpb25z
IHRoYXQgbmVlZCB0byBkZWFsIHdpdGggdGhpcyBwcm9ibGVtIGFyZSBpbXBhY3RlZCBieSBpdC4N
Cg0KU3Ryb25nbHkgZGlzYWdyZWUuICBUaGlzIHJlcXVpcmVzIGFwcGxpY2F0aW9ucyB0byBrbm93
IHdheSB0byBtdWNoIGFib3V0IHRoZSBUTFMgbGF5ZXI6ICB3aGF0IGNpcGhlciBpcyBiZWluZyB1
c2VkLCBob3cgU1NMIGlzIHBhY2tpbmcgdGhpbmdzIGludG8gcmVjb3JkcywgYW5kIGhvdyBvZnRl
biBhIGNpcGhlciBuZWVkcyB0byBiZSDigJxyZXNldOKAnSBhbmQgd2hhdCB0aGF0IGVudGFpbHMu
DQoNCi0tDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2dpZXMs
IENhbWJyaWRnZSwgTUENCklNOiByc2FsekBqYWJiZXIubWU8bWFpbHRvOnJzYWx6QGphYmJlci5t
ZT47IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg==

--_000_2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141CUSMBX1msgcorp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K
CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7
fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp
di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u
TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1
cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg
bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu
LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy
aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov
DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNzM0MzE4MTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJy
aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTQ2NTc2NDg4IC05MzU0NTAwOCA2NzY5ODY5
MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz
dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h
cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv
ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp
b24xPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjtt
c28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPjxz
cGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsOYPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRp
bWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhl
IGFkdmFudGFnZSB3aXRoIHRoaXMgaXMgdGhhdCBvbmx5IHRoZSBhcHBsaWNhdGlvbnMgdGhhdCBu
ZWVkIHRvIGRlYWwgd2l0aCB0aGlzIHByb2JsZW0gYXJlIGltcGFjdGVkIGJ5IGl0Ljxicj48YnI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U3Ryb25nbHkgZGlzYWdyZWUuwqAgVGhpcyBy
ZXF1aXJlcyBhcHBsaWNhdGlvbnMgdG8ga25vdyB3YXkgdG8gbXVjaCBhYm91dCB0aGUgVExTIGxh
eWVyOsKgIHdoYXQgY2lwaGVyIGlzIGJlaW5nIHVzZWQsIGhvdyBTU0wgaXMgcGFja2luZyB0aGlu
Z3MgaW50byByZWNvcmRzLCBhbmQgaG93IG9mdGVuIGEgY2lwaGVyIG5lZWRzIHRvIGJlIOKAnHJl
c2V04oCdIGFuZCB3aGF0IHRoYXQgZW50YWlscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0twqAgPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ba2FtYWkgVGVjaG5vbG9naWVz
LCBDYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklNOiA8YSBocmVmPSJtYWlsdG86cnNhbHpAamFiYmVyLm1l
Ij48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+cnNhbHpAamFiYmVyLm1lPC9zcGFuPjwvYT47IFR3
aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48
L2JvZHk+PC9odG1sPg==

--_000_2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141CUSMBX1msgcorp_--


From nobody Wed May 28 13:12:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351E91A029F for ; Wed, 28 May 2014 13:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhhB4BEb5G04 for ; Wed, 28 May 2014 13:12:32 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6951A0051 for ; Wed, 28 May 2014 13:12:32 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id k48so11763094wev.5 for ; Wed, 28 May 2014 13:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zIvfL1LxwNr379SMNDwn3htTDd6levJNPal+TSnEdGc=; b=kDU+w4PuJ+fWhm+XIEYRVYbsTBmsHOyA72NP3n7hgQFDdcH3HsLZCVpQayvgcMaXDu lVoBHQ7j2sonZLFUQOupNz81NG9k5H977ugrgcPJ9VG4Ig82+kTRp7BueO2yV/vUwFo4 +OShGnY9l0dbuEYu0avHdrSi+5DC/Pevm2iJ17vL7Z2GSeCGWG+IMH3SWt3ZNVI+m6aA 3Oghru9Xa6YNbQexIpkIsQGm67TR0foW6bs4++4DnqlQR+k4nD7Sbr9Iu1jhXm/wJTWA WXC2D6xgQ+KnjI3fZHy+NGcyyOaQFMTixZWIdkZWq2gJfVhIUbTOpLmTZagy8QnHvyZQ c/wg==
MIME-Version: 1.0
X-Received: by 10.180.72.243 with SMTP id g19mr52612244wiv.44.1401307947544; Wed, 28 May 2014 13:12:27 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 13:12:27 -0700 (PDT)
In-Reply-To: <53863F1D.3060707@amacapital.net>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>  <53863F1D.3060707@amacapital.net>
Date: Wed, 28 May 2014 13:12:27 -0700
Message-ID: 
From: Martin Thomson 
To: Andy Lutomirski 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v4O9-sojhlkfstfjGrAn92moMGA
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:12:34 -0000

On 28 May 2014 12:55, Andy Lutomirski  wrote:
> Separately derive master_secret and temporary_secret from
> premaster_secret.  Use master_secret as it's currently used for
> resumption, but use temporary_secret for encryption and MAC.  When it's
> time to rekey, roll over the temporary_secret but leave the
> master_secret alone.

The problem with that is that you end up with the keys to the kingdom
just lying around.  And they only seem to exist in order to enable
resumption.  One property I was looking to gain here was the ability
to have a state that cannot be used to derive past states.  Having the
master_secret sitting around loses that.

> Getting resumption right might be a little tricky here: unless a new DH
> exchange happens on resumption, the new temporary_secret will have to be
> derived from master_secret.

The whole point is to avoid the DH.  The current resumption process
mixes new randoms with the old master_secret.  The old master_secret
is then discarded.  That would seem to have the property you are
looking at.


From nobody Wed May 28 13:12:49 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F71A06B8 for ; Wed, 28 May 2014 13:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.848
X-Spam-Level: 
X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUGGAOZ694Ll for ; Wed, 28 May 2014 13:12:39 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05E1A0692 for ; Wed, 28 May 2014 13:12:39 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4SKCE4M007857; Wed, 28 May 2014 16:12:32 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "Salz, Rich" , Brian Smith , Martin Thomson 
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: AQHPefQo4YWfXkMh6EK4g8davOzARJtVv9sAgAC14oCAADgXAIAAAbsA//++vYA=
Date: Wed, 28 May 2014 20:12:19 +0000
Message-ID: 
References:     <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [172.25.177.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484138329_6645087"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-05-28_07:2014-05-28,2014-05-28,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405280255
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bj6FyCMtY5MZVk28gy7jcTQdHRI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:12:44 -0000

--B_3484138329_6645087
Content-type: multipart/alternative;
	boundary="B_3484138329_6690306"


--B_3484138329_6690306
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

> =C3=98 The advantage with this is that only the applications that need to dea=
l with
> this problem are impacted by it.
>=20
>=20
> Strongly disagree.  This requires applications to know way to much about =
the
> TLS layer:  what cipher is being used, how SSL is packing things into rec=
ords,
> and how often a cipher needs to be =E2=80=9Creset=E2=80=9D and what that entails.

Concur. Rekeying of an otherwise healthy connection must be the TLS job, an=
d
must be done automatically.




--B_3484138329_6690306
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

<=
blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4=
df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
=C3=98=
 
The advantage with this is that only the=
 applications that need to deal with this problem are impacted by it.
St=
rongly disagree.  This requires applications to know way to much about =
the TLS layer:  what cipher is being used, how SSL is packing things in=
to records,
 and how often a cipher needs to be “reset” and what that entai=
ls.

Conc=
ur. Rekeying of an otherwise healthy connection must be the TLS job, and mus=
t be done automatically.



--B_3484138329_6690306--

--B_3484138329_6645087
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP
8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5
pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi
ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj
akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu
ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T
eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m
1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2
BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ
NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk
u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK
PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y
MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4
YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C
PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2
QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D
1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB
kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB
BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE
VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ
BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ
iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw
7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8
c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt
DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX
X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE
BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET
MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG
SIb3DQEJBDEiBCBAuvNLCYLx8c0i4lzPDPmqoodGroSKpIk33Tvs/9foxDAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjgyMDEyMDlaMA0GCSqGSIb3
DQEBAQUABIIBAJKANXEnlKtmrdGr2KIw7u/awolr2t/+rRMEaKZw7wZJJ4/wHEc/6n1A+AKQ
ogZBsmHzj5tr6poV2JaEX935vvwRDcNjhwTI0PqXkd21sQvXUDHa5BkOUaixEv4i9qWi2+jP
zM4w0+9CB2D4vkxuiRJDcpnrfb1v+SMMbI+LBqQn1vmXuqU4viMsVB6ibWFlpavVlLsCjqmX
ys/snYZRcw9xE0t3n7UHUSta4GkWwVBOOLx5boiKfitG6G1WJOkCE5kZW3n5AjYOkKVgSf9y
bzAy98XQuTzAfc6YWbn9ojyt4xf8QBbE5TJpi/J/AJkm2esic5f/Nqk+sxkUG3gtb3k=

--B_3484138329_6645087--


From nobody Wed May 28 13:15:38 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF21A029F for ; Wed, 28 May 2014 13:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHBUxSVGnqxy for ; Wed, 28 May 2014 13:15:35 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 8C37E1A0051 for ; Wed, 28 May 2014 13:15:35 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B53B6481B0; Wed, 28 May 2014 20:15:31 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A9C1948199; Wed, 28 May 2014 20:15:31 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 914DB1E03D; Wed, 28 May 2014 20:15:31 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 28 May 2014 16:15:31 -0400
From: "Salz, Rich" 
To: Martin Thomson , Andy Lutomirski 
Date: Wed, 28 May 2014 16:15:30 -0400
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: Ac96sSymbtu3UdjhS1OilrWOAoLbtgAAClGA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C1428@USMBX1.msg.corp.akamai.com>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>  <53863F1D.3060707@amacapital.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bczc-rPNKLNJTVp-ivWQ3FQrVaE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:15:36 -0000

> The whole point is to avoid the DH. =20

I'm not sure that should be a major design point.  For the one use-case we =
know, do we know if those long lived xmpp connections are to small clients =
(such as android phones) or server to server?

	/r$

-- =20
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSalz


From nobody Wed May 28 13:16:02 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80091A0417 for ; Wed, 28 May 2014 13:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZcVuXzHfsAA for ; Wed, 28 May 2014 13:15:58 -0700 (PDT)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CFF1A0051 for ; Wed, 28 May 2014 13:15:57 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id n12so11811204wgh.5 for ; Wed, 28 May 2014 13:15:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mVHSqVi/5xK56tVEsAm2AFeEsaNFnKeqGY8sLbvwun0=; b=cGWvtyAimax1CbXEpt3CRSWf3gg/NUpZybV7K1XgHWR0oDLqPqNh6RjA/RJUOOK8if iWtSnVEZQuy2ywkM602qaOakJWN178QTguNIf+lAv+MIpZ1lB5m9tdG4ozWNLIsgvn6x nUzgIXNYCSQDO5PfNuqqgdTc4C0K8wLfc2PIHRSVurnjF41bI9jD0VeNwby8YCyBEMoH cUyFx8R75swMS4NsbhEn7jh4qhYmijERwbZ2bZvWTNXNkMheEsuxA4nzO02uRcnrFoYX orEHN8S5kgjO0SjPMP3LjINZ/VwFc3ue7FR5n4ppZtLoqod/lWkkR+UEmPbyr5mE+Lvo 5zHQ==
X-Gm-Message-State: ALoCoQm3FJFWgyT1c/eUfebDcPU6i3iqvLd7EAZwp0L2+b9BdIsd2ErTKe2AnAeNQlcXETnxLeCl
X-Received: by 10.194.62.176 with SMTP id z16mr2939514wjr.76.1401308152877; Wed, 28 May 2014 13:15:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Wed, 28 May 2014 13:15:12 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:7931:db29:b29d:2f29]
In-Reply-To: <53863F1D.3060707@amacapital.net>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>  <53863F1D.3060707@amacapital.net>
From: Eric Rescorla 
Date: Wed, 28 May 2014 13:15:12 -0700
Message-ID: 
To: Andy Lutomirski 
Content-Type: multipart/alternative; boundary=047d7ba979c2ac6e4204fa7b7aa9
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/me6pNhw2XAP2PdjDG48z_2F9Kwc
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:16:00 -0000

--047d7ba979c2ac6e4204fa7b7aa9
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 12:55 PM, Andy Lutomirski wrote:

> On 05/28/2014 10:02 AM, Martin Thomson wrote:
> > On 27 May 2014 17:44, Martin Rex  wrote:
> >> Conceptually, the TLS session cache is readonly after an entry
> >> is created, and that is GOOD, i.e. full TLS handshakes create new,
> >> distict session cache entries, and abbreviated TLS handshakes resume
> >> existing session cache entries and *NEVER* modify them.
> >
> > That's a good point.  Something that I missed.  A resumption handshake
> > would have to include an epoch from the previous session.  That number
> > would need to be incremented with each update of the master secret.
>
> Rather than mucking with the master secret, can't we rearrange the key
> hierarchy a bit:
>
> Separately derive master_secret and temporary_secret from
> premaster_secret.  Use master_secret as it's currently used for
> resumption, but use temporary_secret for encryption and MAC.  When it's
> time to rekey, roll over the temporary_secret but leave the
> master_secret alone.
>
> Getting resumption right might be a little tricky here: unless a new DH
> exchange happens on resumption, the new temporary_secret will have to be
> derived from master_secret.
>

This seems like it would seriously decrease the value of resumption.

-Ekr




>
> --Andy
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7ba979c2ac6e4204fa7b7aa9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, May 28, 2014 at 12:55 PM, Andy Lutomirski <luto@amacapit=
al.net> wrote:



On 05/28/2014 10:02 AM, Mart=
in Thomson wrote:

> On 27 May 2014 17:44, Martin Rex <m=
rex@sap.com> wrote:

>> Conceptually, the TLS session cache is readonly after an entry

>> is created, and that is GOOD, i.e. full TLS handshakes create new,=


>> distict session cache entries, and abbreviated TLS handshakes resu=
me

>> existing session cache entries and *NEVER* modify them.

>

> That's a good point. =C2=A0Something that I missed. =C2=A0A resump=
tion handshake

> would have to include an epoch from the previous session. =C2=A0That n=
umber

> would need to be incremented with each update of the master secret.



Rather than mucking with the master secret, can't we rearrange th=
e key

hierarchy a bit:



Separately derive master_secret and temporary_secret from

premaster_secret. =C2=A0Use master_secret as it's currently used for
resumption, but use temporary_secret for encryption and MAC. =C2=A0When it&=
#39;s

time to rekey, roll over the temporary_secret but leave the

master_secret alone.



Getting resumption right might be a little tricky here: unless a new DH

exchange happens on resumption, the new temporary_secret will have to be
derived from master_secret.

This seems =
like it would seriously decrease the value of resumption.

-Ekr









--Andy




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--047d7ba979c2ac6e4204fa7b7aa9--


From nobody Wed May 28 13:17:37 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A955F1A0051 for ; Wed, 28 May 2014 13:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqyEDf2ffnAe for ; Wed, 28 May 2014 13:17:31 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276A61A029F for ; Wed, 28 May 2014 13:17:31 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id n15so4359926wiw.9 for ; Wed, 28 May 2014 13:17:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=45Mp8iaYPO4xlaSdlL5tlGw80MJHzrrL0lbZONK7kXE=; b=rm15vPAjTk09wTewu1M2K3wYShL73vzJL4rp1b2b0S7i+/N/oMmTJ49eNqrQJTGdNX HIW2Pph2khpg737FZxBPyaDtJjdppXXPrDQHJ/4ac8tPOalF626fw/P5n2xWebywmpwn 638PYF58gr2MC3MrKD4AjFZ9vG8oMJ7bQnFEEaeDOq5nykqeXeOmb9kS/zXkbTrpRPO1 r57xu3zafyX5KjPKQnDJNJ9BcaJlA1sHaFmzfY7UI2YfCyjcmlND28SJcmB5KIxSJpF4 Cw9a5L3rP8IMFtuzSt0gkbVVjEOMH5FFmUVNN6wq7qV6ni0caAkfUgkn/oi2VfS6+Xok CsNw==
MIME-Version: 1.0
X-Received: by 10.180.19.233 with SMTP id i9mr3169620wie.38.1401308244563; Wed, 28 May 2014 13:17:24 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 13:17:24 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C1428@USMBX1.msg.corp.akamai.com>
References:  <20140528004408.D184F1AD1D@ld9781.wdf.sap.corp>  <53863F1D.3060707@amacapital.net>  <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C1428@USMBX1.msg.corp.akamai.com>
Date: Wed, 28 May 2014 13:17:24 -0700
Message-ID: 
From: Martin Thomson 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GsVgnnqPNaxWJD2z3ttomUXaRno
Cc: "tls@ietf.org" , Andy Lutomirski 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:17:32 -0000

On 28 May 2014 13:15, Salz, Rich  wrote:
>> The whole point is to avoid the DH.
>
> I'm not sure that should be a major design point.  For the one use-case we know, do we know if those long lived xmpp connections are to small clients (such as android phones) or server to server?

People who like resumption keep saying that this is the primary
advantage.  Maybe they like the latency advantage, but most of that
would be obviated by faster handshakes, or false start.


From nobody Wed May 28 13:47:48 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B251A0227 for ; Wed, 28 May 2014 13:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYxvWkVlSHjq for ; Wed, 28 May 2014 13:47:45 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E854F1A020B for ; Wed, 28 May 2014 13:47:44 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id 63so19626951qgz.16 for ; Wed, 28 May 2014 13:47:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GseFhq3iy8iK0NFkqy4urL0Hnoof9pkBfKi9q2LAMI0=; b=Br3tjh5kCXU5zh6U6vg2sQ5Rfuv6tK8ynVRtQCtB50hC2SceHMMPYlnl9BKOEbztyc 88tTzYacrbsoYnGBoIvdl2NfQD6LdkoH5+JREk74Q5gBtSg/oOuX1AEzyTEMKfqnzwVB yi02pJ8ReKVmDunqnG2S9R4NTa0no97mw6z7yRvXZq2+JdBCj1aktjuxQFq2K4iJxBEl kBMjiARC5dp6ABdxiLwsQEcbTUhQ/ZafQO331ddbzOFYIc0NrO+LfkajcGHtb9o4UEpa Wk3Pc8aWx4bYjEDMWoJUvXrqbg4hjxWebBqVS6RKk41xtSzq8rLLfm+EP4effg/VBEqI jUFw==
X-Gm-Message-State: ALoCoQlzg29FAWRud+TIVTOrR1bjaUG6FeGDrvnx4kzAgWVriK2PPu5vAWpDlAa4oSIpIem8cMh8
MIME-Version: 1.0
X-Received: by 10.140.28.3 with SMTP id 3mr3001350qgy.71.1401310060641; Wed, 28 May 2014 13:47:40 -0700 (PDT)
Received: by 10.224.201.193 with HTTP; Wed, 28 May 2014 13:47:40 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
References:     <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C141C@USMBX1.msg.corp.akamai.com>
Date: Wed, 28 May 2014 13:47:40 -0700
Message-ID: 
From: Brian Smith 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a113a34e462932904fa7bec96
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yexQF2vK9YQiHRP-phsg3TtEMQ4
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 20:47:46 -0000

--001a113a34e462932904fa7bec96
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 28, 2014 at 1:05 PM, Salz, Rich  wrote:

> =C3=98  The advantage with this is that only the applications that need t=
o
> deal with this problem are impacted by it.
>
> Strongly disagree.  This requires applications to know way to much about
> the TLS layer:  what cipher is being used, how SSL is packing things into
> records, and how often a cipher needs to be =E2=80=9Creset=E2=80=9D and w=
hat that entails.
>

The application would only have to be aware that the connection may at some
point become unusable because the TLS implementation did something like
simulating a RST when some crypto limit is reached. Applications that are
exchanging more than 2^32 records per connection already have to cope
somehow with these long-lived connections being reset below the TLS layer.

And/or such applications could choose to use cipher suites that aren't
limited to 2^32 records. I have just re-read SP-800-38D section 8.3 which
sets the limit on the number of invocations of AES-GCM with a given key.
SP-800-38D doesn't actually limit AES-GCM to 2^32 invocations as long as
the deterministic construction is used and as long as the invocation field
is larger than 32 bits, if I am reading it correctly. The birthday attack
issue on the 64-bit invocation field used in AES-GCM cipher suites could be
mitigated by tightening the requirements for AES-GCM in TLS 1.3 and/or by
defining new AES-GCM cipher suites that are required to have IVs generated
using the deterministic construction with large(r) invocation fields.

And/or, implementations that send/receive large amounts of data on a single
connection could tune their TLS stacks so that they will never (or almost
never) get close to whatever limit the cipher suite has.

And/or the TLS implementation could optionally provide some kind of simple
notification mechanism to tell the application that the connection will
become unusable "soon," so that an application could start a new
connection/session before the old one stops working, to minimize the
performance impact.

Cheers,
Brian

[1] http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf(secti=
on
8.3)

--001a113a34e462932904fa7bec96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, May 28, 2014 at 1:05 PM, Salz, Rich <rsalz@akamai.com> wr=
ote:


=C3=98=C2=A0 The advantage with this is that only the applications that need=
 to deal with this problem are impacted by it.


=
Strongly disagree.=C2=A0 This requires applicati=
ons to know way to much about the TLS layer:=C2=A0 what cipher is being use=
d, how SSL is packing things into records, and how often a cipher needs to =
be =E2=80=9Creset=E2=80=9D and what that entails.



The application would only hav=
e to be aware that the connection may at some point become unusable because=
 the TLS implementation did something like simulating a RST when some crypt=
o limit is reached. Applications that are exchanging more than 2^32 records=
 per connection already have to cope somehow with these long-lived connecti=
ons being reset below the TLS layer.


And/or such applications could choose to use cipher suites t=
hat aren't limited to 2^32 records. I have just re-read SP-800-38D sect=
ion 8.3 which sets the limit on the number of invocations of AES-GCM with a=
 given key. SP-800-38D doesn't actually limit AES-GCM to 2^32 invocatio=
ns as long as the deterministic construction is used and as long as the inv=
ocation field is larger than 32 bits, if I am reading it correctly. The bir=
thday attack issue on the 64-bit invocation field used in AES-GCM cipher su=
ites could be mitigated by tightening the requirements for AES-GCM in TLS 1=
.3 and/or by defining new AES-GCM cipher suites that are required to have I=
Vs generated using the deterministic construction with large(r) invocation =
fields.


And/or, implementations that send/receive large amounts of data on a si=
ngle connection could tune their TLS stacks so that they will never (or alm=
ost never) get close to whatever limit the cipher suite has.

And/or =
the TLS implementation could optionally provide some kind of simple notific=
ation mechanism to tell the application that the connection will become unu=
sable "soon,"
 so that an application could start a new connection/session before the=20
old one stops working, to minimize the performance impact.


--001a113a34e462932904fa7bec96--


From nobody Wed May 28 15:25:11 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39351A06E8 for ; Wed, 28 May 2014 15:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDGUZEF7Ge8T for ; Wed, 28 May 2014 15:25:06 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731951A04B6 for ; Wed, 28 May 2014 15:25:06 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id A388533D002; Wed, 28 May 2014 22:25:02 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Martin Thomson 
References:   
From: Geoffrey Keating 
Date: 28 May 2014 15:25:02 -0700
In-Reply-To: 
Message-ID: 
Lines: 38
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EHmCXQekykm8_d5B_Oe0st1lcbo
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 22:25:09 -0000

Martin Thomson  writes:

> On 27 May 2014 22:47, Brian Smith  wrote:
> >> It's not possible to just remove renegotiation.
> >
> >
> > Why not? What is the motivation for keeping any form of renegotiation, even
> > rekeying? It isn't clear from the public mailing list discussions what is
> > motivating the rekeying feature. (Perhaps I overlooked something; if so, a
> > link to the past decision on this would be appreciated.)
> 
> That statement was merely referring to the fact that there are other
> considerations that removing renegotiation exposes:
> 
> AES-GCM (for example) can't be used with the same key indefinitely.
> 2^32 records is the limit apparently.  We have reports of services
> that use the same connection for up to months with high volumes of
> traffic.  Over that period, the sequence number might roll over, even
> if the keys are still good.  Rekeying allows for those uses.

I think this should be handled by TLS, not by having the application
request rekeying or renegotiation.  If TLS handles it, I don't see why
there's a need for a special 'renegotiate' or 'change key' message; it
can quietly change the key when the appropriate limit is hit.

For sequence numbers, rollover also should (indeed must) be handled by
DTLS.  There are many possibilities, but the easiest is that if we're
removing renegotiation, so the cipher state can change at most once,
so in DTLS we can remove the epoch counter and make the sequence
number 64-bit, and say that if the 64-bit counter is exceeded (will
probably never happen) it is an error and the connection should close.

> It also provides a measure of forward security in that old keys can be
> thrown away.  A break of a server only allows the attacker to gain the
> plaintext of a connection back to the last rekeying event.

This definitely seems like a case where you want to close the
connection and open a new one, directed by the application.


From nobody Wed May 28 15:45:27 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2973B1A0721 for ; Wed, 28 May 2014 15:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-pXZFu5Vkjo for ; Wed, 28 May 2014 15:45:24 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16D71A071D for ; Wed, 28 May 2014 15:45:23 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id x12so11821652wgg.33 for ; Wed, 28 May 2014 15:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YUOZQL9eCnvA/Py01+UgEL/O1Np7kh3KogpMXvAe0lM=; b=HfrH8Qz30QjDkN1TFgrrEXUyF7DjNl0Azq1nKTDeOxiYDq+LE9YJxQSsc9nBaTyFSw qSAAViveEzzqLQJJMRSk32jNyAF71rdccNPxdj2Bl7mPfE+FzFl6PzrFfIALpFurTxZ+ Cwzho022Gnc3qXj5/tLIioOP/cF/0zS3ADkJubjP8cQ67tveHkpoulk3IzFbgoBPJKLH y/Kv0YDUR+iBR/6T2D/gLXn0NEWmjPR09Qc1jOo44tciR2UPRpIJRohthSvXC9ZZH9d8 6Qlelumwy83+yR5Ct589h8Fz8L6OItEpZem2kQQdCyR58zp/pyfnPJoPYx6kqwh62/6x nw4A==
MIME-Version: 1.0
X-Received: by 10.194.133.1 with SMTP id oy1mr3787071wjb.87.1401317119018; Wed, 28 May 2014 15:45:19 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 15:45:18 -0700 (PDT)
In-Reply-To: 
References:    
Date: Wed, 28 May 2014 15:45:18 -0700
Message-ID: 
From: Martin Thomson 
To: Geoffrey Keating 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_scw3Dm4Aly8R0x54iNC5J_KsB8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 May 2014 22:45:25 -0000

On 28 May 2014 15:25, Geoffrey Keating  wrote:
> I think this should be handled by TLS, not by having the application
> request rekeying or renegotiation.  If TLS handles it, I don't see why
> there's a need for a special 'renegotiate' or 'change key' message; it
> can quietly change the key when the appropriate limit is hit.

I wasn't proposing that the application be in control of when rekeying
occurs.  (Yes, if an app needs an explicit break in continuity, then
opening a new connection is a perfectly reasonable way to achieve that
goal.)

Yes, you could just roll on through, identify a point where rekeying
is necessary and automatically do it.  That's even more aggressively
spartan than what I've proposed.

A message enables more than just necessary rekeying.  It also allows
for read and write states to be kept in sync.

It also means that you don't have to go to great lengths to contrive a
rekeying scenario in your testing.  I certainly don't want rekeying to
be rare enough that it breaks the first time that it ever actually
happens.  That's a surefire plan for backup generator syndrome.


From nobody Wed May 28 21:13:08 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3AD1A084F for ; Wed, 28 May 2014 21:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBSNDeWH_Ohm for ; Wed, 28 May 2014 21:13:04 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784FE1A0859 for ; Wed, 28 May 2014 21:13:04 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.96.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 128F950A73 for ; Thu, 29 May 2014 00:12:57 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Thu, 29 May 2014 14:12:54 +1000
To: TLS Mailing List 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sBBPkCeJEA8RLqV3oduCLpdwX08
Subject: [TLS] Requiring SNI for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 04:13:06 -0000

Hey TLS WG,

Recently, I migrated two of the Web sites that I host to TLS-only, using =
the same IP address (and thus using SNI).

The details are here:
  https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing

When doing so, I decided to require SNI, returning an error when it =
isn't presented. This seemed like the logical thing to do; after all, if =
the client doesn't present SNI, it might be presented with =
www.mnot.net's cert when the browser thinks it's going to redbot.org, =
and the user gets a cert error dialog. I don't want to contribute to =
training them to click through those...

Anyway, a couple of questions for your collective wisdom.

1) For HTTPS, is it reasonable for rejecting SNI-less requests to be the =
default when the server actually uses SNI to dispatch to the correct =
origin? (This may be a better question for WEBSEC or elsewhere, but I =
thought I'd ask here first). Right now in Apache, you have to go pretty =
far out of your way to get this behaviour.

2) When rejecting an SNI-less request, Apache currently generates a 403 =
Forbidden. However, I actually suspect that a 400 Bad Request (or a new =
status code) would be more appropriate, since 400 is also used when Host =
isn't available, and this is directly analogous.=20

See also the Apache bug I raised about this: =
. In =
particular, I don't see how sites can reasonably start requiring SNI =
until server-side software makes it easier to serve an error document =
explaining what's happening to users that don't emit it.

Any thoughts?

Cheers,


--
Mark Nottingham   https://www.mnot.net/




From nobody Wed May 28 22:14:30 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD19B1A070F for ; Wed, 28 May 2014 22:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1giLXIw005cj for ; Wed, 28 May 2014 22:14:25 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84FC1A0329 for ; Wed, 28 May 2014 22:14:24 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id q58so3500830wes.39 for ; Wed, 28 May 2014 22:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Bav6qyfo0aA0DQewXhwu014avox558pOyhmPPoPGwQ=; b=R0jDaa06szceYNx7D4yUvfToT5uX19ZVvlWNJBhIzzExGhssxpPbjLUieoZJBbONPE 4oxrpBej7GfX+bMSrzna9j+1FhxKnZcvpf1QkkM7IQb2nbTcxNMi/eWqbREHEPrB7lMo dJwJRfOhCdUYgFfjaOWYelreLBwLSgvJ0tJYPj6PkYOPJvLEMoDl7mAjXQmrjbgCNy4W COebt1aBTWR2ED/DGjmuuwn1JMEgYGyGkZIp+OzPnN+RqZb4pAdRiwHFEpAS5gt0eiD9 x7CZz4XZeNDgniqeYoPpc/aCodiDeCuuX0Oby8T0oJqagrYDKVhPB4eYIi3oe3TwSrPN kIfA==
X-Received: by 10.194.1.242 with SMTP id 18mr6843564wjp.22.1401340459817; Wed, 28 May 2014 22:14:19 -0700 (PDT)
Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id vm8sm48752234wjc.27.2014.05.28.22.14.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 22:14:19 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir 
In-Reply-To: 
Date: Thu, 29 May 2014 08:14:16 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <18C56F3F-180C-4515-8EF7-9C3546D401D6@gmail.com>
References: 
To: Mark Nottingham 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w43zP_SO6_djbi47fSFHoqT0AWs
Cc: TLS Mailing List 
Subject: Re: [TLS] Requiring SNI for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 05:14:27 -0000

Hi Mark

On May 29, 2014, at 7:12 AM, Mark Nottingham  wrote:

> Hey TLS WG,
>=20
> Recently, I migrated two of the Web sites that I host to TLS-only, =
using the same IP address (and thus using SNI).
>=20
> The details are here:
>  =
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
>=20
> When doing so, I decided to require SNI, returning an error when it =
isn't presented. This seemed like the logical thing to do; after all, if =
the client doesn't present SNI, it might be presented with =
www.mnot.net's cert when the browser thinks it's going to redbot.org, =
and the user gets a cert error dialog. I don't want to contribute to =
training them to click through those=85

Reading up to this, I thought that the client was sending a ClientHello =
without SNI, and the server was closing the connection with an alert =
and/or a RST.  But reading on, you talk about HTTP codes. If you=92re =
getting to the stage where you=92re sending HTTP codes to the client, =
you are way past any warning screens about mismatched domain names. If =
the user was going to click through, she=92d already done so.

> Anyway, a couple of questions for your collective wisdom.
>=20
> 1) For HTTPS, is it reasonable for rejecting SNI-less requests to be =
the default when the server actually uses SNI to dispatch to the correct =
origin? (This may be a better question for WEBSEC or elsewhere, but I =
thought I'd ask here first). Right now in Apache, you have to go pretty =
far out of your way to get this behaviour.

SNI is an extension. As of now, it=92s not mandatory. It might be in TLS =
1.3, but it=92s not mandatory now. So what you are describing is =
rejecting clients that are standards compliant. That said, I don=92t =
think you=92re providing a government service with requirements for =
accessibility, so if you=92re fine with rejecting that user with IE on =
XP or Safari on 10.4, it=92s your choice.  It=92s probably less than 15% =
of browsers (based on 20% being XP and IE being more popular there than =
on other platforms)

> 2) When rejecting an SNI-less request, Apache currently generates a =
403 Forbidden. However, I actually suspect that a 400 Bad Request (or a =
new status code) would be more appropriate, since 400 is also used when =
Host isn't available, and this is directly analogous.=20
>=20
> See also the Apache bug I raised about this: =
. In =
particular, I don't see how sites can reasonably start requiring SNI =
until server-side software makes it easier to serve an error document =
explaining what's happening to users that don't emit it.
>=20
> Any thoughts?
>=20
> Cheers,
>=20
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Wed May 28 22:33:13 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8351A075A for ; Wed, 28 May 2014 22:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level: 
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwX1H3eaBn6B for ; Wed, 28 May 2014 22:33:07 -0700 (PDT)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C811A030A for ; Wed, 28 May 2014 22:33:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="112331796"
X-IPAS-Result: AqQEADD7RVPAqArr/2dsb2JhbABZg0FXvEEdhzWBN3SCJQEBAQEDAQEBNw8lFwQCAQgNAQMEAQELFAkHJwsUCQgCBAESCBSHbcwQEwSOOzgGgx6BFASfWY53gis
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 29 May 2014 05:33:04 +0000
Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 28 May 2014 22:33:03 -0700
From: David Holmes 
To: Mark Nottingham , TLS Mailing List 
Thread-Topic: [TLS] Requiring SNI for HTTPS
Thread-Index: AQHPevRMgX9NK94NLUWDO5/1+ywN2JtXB++g
Date: Thu, 29 May 2014 05:33:02 +0000
Deferred-Delivery: Thu, 29 May 2014 05:33:00 +0000
Message-ID: <859F43324A6FEC448BFEA30C90405FA9048C30@SEAEMBX02.olympus.F5Net.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.16.250]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W7xHd6svFCfcQIFNTDichYtps4Y
Subject: Re: [TLS] Requiring SNI for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 05:33:09 -0000

Do you have any visibility into what percentage of visitors are now getting=
 blocked? Either because they don't have TLS or because they don't present =
SNI? Or both?

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Mark Nottingham
Sent: Wednesday, May 28, 2014 9:13 PM
To: TLS Mailing List
Subject: [TLS] Requiring SNI for HTTPS

Hey TLS WG,

Recently, I migrated two of the Web sites that I host to TLS-only, using th=
e same IP address (and thus using SNI).

The details are here:
  https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing

When doing so, I decided to require SNI, returning an error when it isn't p=
resented. This seemed like the logical thing to do; after all, if the clien=
t doesn't present SNI, it might be presented with www.mnot.net's cert when =
the browser thinks it's going to redbot.org, and the user gets a cert error=
 dialog. I don't want to contribute to training them to click through those=
...

Anyway, a couple of questions for your collective wisdom.

1) For HTTPS, is it reasonable for rejecting SNI-less requests to be the de=
fault when the server actually uses SNI to dispatch to the correct origin? =
(This may be a better question for WEBSEC or elsewhere, but I thought I'd a=
sk here first). Right now in Apache, you have to go pretty far out of your =
way to get this behaviour.

2) When rejecting an SNI-less request, Apache currently generates a 403 For=
bidden. However, I actually suspect that a 400 Bad Request (or a new status=
 code) would be more appropriate, since 400 is also used when Host isn't av=
ailable, and this is directly analogous.=20

See also the Apache bug I raised about this: . In particular, I don't see how sites can re=
asonably start requiring SNI until server-side software makes it easier to =
serve an error document explaining what's happening to users that don't emi=
t it.

Any thoughts?

Cheers,


--
Mark Nottingham   https://www.mnot.net/



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From nobody Thu May 29 00:27:29 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FED51A0382 for ; Thu, 29 May 2014 00:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcDn7mX2rJlK for ; Thu, 29 May 2014 00:27:26 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F2B1A01B2 for ; Thu, 29 May 2014 00:27:26 -0700 (PDT)
Received: from [192.168.1.55] (unknown [118.209.96.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 26687509B5; Thu, 29 May 2014 03:27:19 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Mark Nottingham 
In-Reply-To: <18C56F3F-180C-4515-8EF7-9C3546D401D6@gmail.com>
Date: Thu, 29 May 2014 17:27:15 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <273FB7B4-7E16-424A-8975-92C39E6D4FEB@mnot.net>
References:  <18C56F3F-180C-4515-8EF7-9C3546D401D6@gmail.com>
To: Yoav Nir 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nhVnDw9phQnh3CmFAtKpNcrx410
Cc: TLS Mailing List 
Subject: Re: [TLS] Requiring SNI for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 07:27:28 -0000

On 29 May 2014, at 3:14 pm, Yoav Nir  wrote:

> Hi Mark
>=20
> On May 29, 2014, at 7:12 AM, Mark Nottingham  wrote:
>=20
>> Hey TLS WG,
>>=20
>> Recently, I migrated two of the Web sites that I host to TLS-only, =
using the same IP address (and thus using SNI).
>>=20
>> The details are here:
>> =
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
>>=20
>> When doing so, I decided to require SNI, returning an error when it =
isn't presented. This seemed like the logical thing to do; after all, if =
the client doesn't present SNI, it might be presented with =
www.mnot.net's cert when the browser thinks it's going to redbot.org, =
and the user gets a cert error dialog. I don't want to contribute to =
training them to click through those=85
>=20
> Reading up to this, I thought that the client was sending a =
ClientHello without SNI, and the server was closing the connection with =
an alert and/or a RST.  But reading on, you talk about HTTP codes. If =
you=92re getting to the stage where you=92re sending HTTP codes to the =
client, you are way past any warning screens about mismatched domain =
names. If the user was going to click through, she=92d already done so.

Right. But, if they click through and get a site, they're rewarded for =
clicking through, which makes it easier for them to click through next =
time.

As a server, my choices are roughly:

a) Serve content based upon the Host header only
b) Serve content if the Host header matches SNI information *or* the =
"default" cert if SNI isn't sent; otherwise serve error content
c) RST if no SNI
d) Serve error content if the user doesn't present SNI.

(a) means that a client that doesn't send SNI will possibly get cert =
errors and possibly click through them to be rewarded with the content =
they want. I don't want to do that.

(b) seems reasonable, but so far, I can't get Apache to do this =
reliably.

(c) is way unfriendly, and doesn't change user behaviour; it just makes =
them think something is wrong with the site.

(d) is the extreme approach that I've currently taken; it requires SNI =
and explains why to those that click through.



> Anyway, a couple of questions for your collective wisdom.
>>=20
>> 1) For HTTPS, is it reasonable for rejecting SNI-less requests to be =
the default when the server actually uses SNI to dispatch to the correct =
origin? (This may be a better question for WEBSEC or elsewhere, but I =
thought I'd ask here first). Right now in Apache, you have to go pretty =
far out of your way to get this behaviour.
>=20
> SNI is an extension. As of now, it=92s not mandatory. It might be in =
TLS 1.3, but it=92s not mandatory now. So what you are describing is =
rejecting clients that are standards compliant. That said, I don=92t =
think you=92re providing a government service with requirements for =
accessibility, so if you=92re fine with rejecting that user with IE on =
XP or Safari on 10.4, it=92s your choice.  It=92s probably less than 15% =
of browsers (based on 20% being XP and IE being more popular there than =
on other platforms)

Yep, I went into this knowing that.

As for non-browser clients, the interesting thing that I saw was that =
many of the search engine spiders still don't emit SNI; the blog entry =
has more details.


>=20
>> 2) When rejecting an SNI-less request, Apache currently generates a =
403 Forbidden. However, I actually suspect that a 400 Bad Request (or a =
new status code) would be more appropriate, since 400 is also used when =
Host isn't available, and this is directly analogous.=20
>>=20
>> See also the Apache bug I raised about this: =
. In =
particular, I don't see how sites can reasonably start requiring SNI =
until server-side software makes it easier to serve an error document =
explaining what's happening to users that don't emit it.
>>=20
>> Any thoughts?
>>=20
>> Cheers,
>>=20
>>=20
>> --
>> Mark Nottingham   https://www.mnot.net/
>>=20

--
Mark Nottingham   https://www.mnot.net/





From nobody Thu May 29 00:49:32 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDE41A0792 for ; Thu, 29 May 2014 00:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgJB9QgXoCO1 for ; Thu, 29 May 2014 00:49:29 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591D51A0789 for ; Thu, 29 May 2014 00:49:29 -0700 (PDT)
Received: from [192.168.1.55] (unknown [118.209.96.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8EA94509B6; Thu, 29 May 2014 03:49:22 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Mark Nottingham 
In-Reply-To: <859F43324A6FEC448BFEA30C90405FA9048C30@SEAEMBX02.olympus.F5Net.com>
Date: Thu, 29 May 2014 17:49:18 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <859F43324A6FEC448BFEA30C90405FA9048C30@SEAEMBX02.olympus.F5Net.com>
To: David Holmes 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7UdB_ju0KqYkJkgMx_145oqxPDw
Cc: TLS Mailing List 
Subject: Re: [TLS] Requiring SNI for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 07:49:31 -0000

It'd dependent upon who's going to my (relatively small) Web sites, of =
course, but at the moment (~ three weeks of logs, IP/user-agent tuple =
identifies unique client):

* For mnot.net, about 5% of clients don't present SNI (out of ~73,000 =
total)
* For redbot.org, only 11% of clients *do* present SNI (out of ~46,000 =
total)

I think the latter is because of the nature of redbot.org; it tends to =
draw abusive bots :-/

No sure way to determine how many visitors can't visit because of =
requirements for TLS (I don't allow SSLv2 or v3,and follow the =
BetterCrypto.org rec's for ciphersuites), but the logs are about as bit =
as before...

The blog entry I mentioned lists some of the more interesting =
non-browser UAs that don't support SNI.

Cheers,


On 29 May 2014, at 3:33 pm, David Holmes  wrote:

> Do you have any visibility into what percentage of visitors are now =
getting blocked? Either because they don't have TLS or because they =
don't present SNI? Or both?
>=20
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Mark Nottingham
> Sent: Wednesday, May 28, 2014 9:13 PM
> To: TLS Mailing List
> Subject: [TLS] Requiring SNI for HTTPS
>=20
> Hey TLS WG,
>=20
> Recently, I migrated two of the Web sites that I host to TLS-only, =
using the same IP address (and thus using SNI).
>=20
> The details are here:
>  =
https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
>=20
> When doing so, I decided to require SNI, returning an error when it =
isn't presented. This seemed like the logical thing to do; after all, if =
the client doesn't present SNI, it might be presented with =
www.mnot.net's cert when the browser thinks it's going to redbot.org, =
and the user gets a cert error dialog. I don't want to contribute to =
training them to click through those...
>=20
> Anyway, a couple of questions for your collective wisdom.
>=20
> 1) For HTTPS, is it reasonable for rejecting SNI-less requests to be =
the default when the server actually uses SNI to dispatch to the correct =
origin? (This may be a better question for WEBSEC or elsewhere, but I =
thought I'd ask here first). Right now in Apache, you have to go pretty =
far out of your way to get this behaviour.
>=20
> 2) When rejecting an SNI-less request, Apache currently generates a =
403 Forbidden. However, I actually suspect that a 400 Bad Request (or a =
new status code) would be more appropriate, since 400 is also used when =
Host isn't available, and this is directly analogous.=20
>=20
> See also the Apache bug I raised about this: =
. In =
particular, I don't see how sites can reasonably start requiring SNI =
until server-side software makes it easier to serve an error document =
explaining what's happening to users that don't emit it.
>=20
> Any thoughts?
>=20
> Cheers,
>=20
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   https://www.mnot.net/





From nobody Thu May 29 05:25:26 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF0E1A0403 for ; Thu, 29 May 2014 05:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEy8u6AmjuiJ for ; Thu, 29 May 2014 05:25:21 -0700 (PDT)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C91A0687 for ; Thu, 29 May 2014 05:25:21 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4TCPE5V028236; Thu, 29 May 2014 08:25:14 -0400
Date: Thu, 29 May 2014 08:25:14 -0400 (EDT)
From: Hubert Kario 
To: Martin Thomson 
Message-ID: <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References:     
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.12]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: Proposed text for removing renegotiation
Thread-Index: 6F0wUuNBJbBcbeHwooFhPtAaBdi2qQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zsTllhM1VWA0J-a52cwmd4x-MEc
Cc: Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 12:25:23 -0000

----- Original Message -----
> From: "Martin Thomson" 
> To: "Geoffrey Keating" 
> Cc: tls@ietf.org
> Sent: Thursday, May 29, 2014 12:45:18 AM
> Subject: Re: [TLS] Proposed text for removing renegotiation
> 
> On 28 May 2014 15:25, Geoffrey Keating  wrote:
> > I think this should be handled by TLS, not by having the application
> > request rekeying or renegotiation.  If TLS handles it, I don't see why
> > there's a need for a special 'renegotiate' or 'change key' message; it
> > can quietly change the key when the appropriate limit is hit.
> 
> I wasn't proposing that the application be in control of when rekeying
> occurs.  (Yes, if an app needs an explicit break in continuity, then
> opening a new connection is a perfectly reasonable way to achieve that
> goal.)
> 
> Yes, you could just roll on through, identify a point where rekeying
> is necessary and automatically do it.  That's even more aggressively
> spartan than what I've proposed.
> 
> A message enables more than just necessary rekeying.  It also allows
> for read and write states to be kept in sync.
> 
> It also means that you don't have to go to great lengths to contrive a
> rekeying scenario in your testing.  I certainly don't want rekeying to
> be rare enough that it breaks the first time that it ever actually
> happens.  That's a surefire plan for backup generator syndrome.

Transferring 64GB of data with TLS over loopback on a relatively modern
machine (even without AES-NI) takes less than an hour. I wouldn't
call it going to great lengths to test.

-- 
Regards,
Hubert Kario


From nobody Thu May 29 07:46:23 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581EF1A6F57 for ; Thu, 29 May 2014 07:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTKSwp9qGydB for ; Thu, 29 May 2014 07:46:20 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C11A0A22 for ; Thu, 29 May 2014 07:46:19 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DDDDE481FD; Thu, 29 May 2014 14:46:15 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id D2723481AB; Thu, 29 May 2014 14:46:15 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id B857698042; Thu, 29 May 2014 14:46:15 +0000 (GMT)
Received: from Tereva.local (172.19.57.221) by usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 29 May 2014 10:46:15 -0400
From: Brian Sniffen 
To: "Salz, Rich" , Martin Thomson 
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C0CE5@USMBX1.msg.corp.akamai.com>
References:  <2A0EFB9C05D0164E98F19BB0AF3708C7130CE35E03@USMBX1.msg.corp.akamai.com>  <2A0EFB9C05D0164E98F19BB0AF3708C7130E4C0CE5@USMBX1.msg.corp.akamai.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0)
Date: Thu, 29 May 2014 10:46:14 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2iaXuSwPqAnfpG0Aratwq1AcROI
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 14:46:22 -0000

"Salz, Rich"  writes:

> Yes, you understand it.  Yes, the trade-offs are like you describe. I happen to think it's cleaner and less likely to have security issues, but we certainly need more discussions. 

One extra trade-off: apps that abstract over sockets and an assumption
they're "secure" will tend to assume a binding between these two TLS
sessions that isn't justified.  If it only happened on very long
sessions, maybe it wouldn't matter in practice---but I expect the case of a
hot-pluggable authenticator to matter.

Airman Smith plugs in his CAC and authenticates to a web server using
the embedded PKCS#11 authenticator.  An hour later, he pulls the CAC and
walks over to the coffeepot.  His browser sees the CAC missing and
issues a CCS.  Five minutes later, Airman Jones inserts her CAC, causing
another CCS.  The browser state is unchanged---cookies persist.

I'd like to avoid encouraging the origin app to mistake this for one
session.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies


From nobody Thu May 29 09:27:36 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EB01A6F8A for ; Thu, 29 May 2014 09:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihgSuhD9Uhzo for ; Thu, 29 May 2014 09:27:34 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CF51A6F7E for ; Thu, 29 May 2014 09:27:32 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id z12so662890wgg.0 for ; Thu, 29 May 2014 09:27:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pliv2QQP3udLsWu5FtGYNq+XCaaHZV8Lk+XXG1AqRuk=; b=ORjSn8a+MrEUrYEo689x/3m2D9qmBab0b5NZKZuNOTWTNJjp2/Hk92TBxD7WhsKW1Q Kgur07ajIkvlYwuzRQplGyDRn1qOC3L9/f+XtkJKTm/sF5DD1y7G7f1mtzvqXhsCMPw/ TSFlB0SidBPsG8j0SnRb6NfEG/XxH8uOobB+LwqiMPHZ4PuhiAGEb4wFvZ18Taw7+3Z4 4GbuKq8NBynkeZvItMwsVP0067O1wpiXiM4Qx9moszA8oMPLjK/5rKmoS8K+Fr9bv8vz 7ZVYHs2Uiu0hNpL2scaTPLdiVwi/IjvVvlzfDfpbtuC95UCseUT7EiCSFnmVb2RnjSNa MHRw==
MIME-Version: 1.0
X-Received: by 10.194.133.1 with SMTP id oy1mr12083781wjb.87.1401380846419; Thu, 29 May 2014 09:27:26 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Thu, 29 May 2014 09:27:26 -0700 (PDT)
In-Reply-To: <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com>
References:      <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com>
Date: Thu, 29 May 2014 09:27:26 -0700
Message-ID: 
From: Martin Thomson 
To: Hubert Kario 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qD1unoCUy7_5jaqafmWrYhOGeRg
Cc: Geoffrey Keating , "tls@ietf.org" 
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 16:27:35 -0000

On 29 May 2014 05:25, Hubert Kario  wrote:
> Transferring 64GB of data with TLS over loopback on a relatively modern
> machine (even without AES-NI) takes less than an hour. I wouldn't
> call it going to great lengths to test.

Seriously?  You think that's an acceptable time to wait for a single
test case to run?  With a message, the test will take milliseconds (as
all tests should).


From nobody Thu May 29 10:00:05 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A761A6F66 for ; Thu, 29 May 2014 10:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level: 
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4ZOdKNzXNjF for ; Thu, 29 May 2014 10:00:00 -0700 (PDT)
Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC831A018C for ; Thu, 29 May 2014 10:00:00 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4TGxsFQ013009; Thu, 29 May 2014 12:59:54 -0400
Date: Thu, 29 May 2014 12:59:53 -0400 (EDT)
From: Hubert Kario 
To: Martin Thomson 
Message-ID: <739427058.16557109.1401382793847.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References:      <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.12]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: Proposed text for removing renegotiation
Thread-Index: S2lO3Im+Q1kl/7KbK3Q9jwsBOkeMWA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vJewmPRSIcnEBSBHTzYLHMJV1Rc
Cc: Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 17:00:04 -0000

----- Original Message -----
> From: "Martin Thomson" 
> To: "Hubert Kario" 
> Cc: "Geoffrey Keating" , tls@ietf.org
> Sent: Thursday, May 29, 2014 6:27:26 PM
> Subject: Re: [TLS] Proposed text for removing renegotiation
> 
> On 29 May 2014 05:25, Hubert Kario  wrote:
> > Transferring 64GB of data with TLS over loopback on a relatively modern
> > machine (even without AES-NI) takes less than an hour. I wouldn't
> > call it going to great lengths to test.
> 
> Seriously?  You think that's an acceptable time to wait for a single
> test case to run?  With a message, the test will take milliseconds (as
> all tests should).

There are test cases and there are test cases.

For a unit test, an hour is definitely far too long, and as you rightfully
point out, a typical unit test should take just few milliseconds.

For an integration test case, an hour is long, but not prohibitive.

For a system test, an hour is basically expected.

-- 
Regards,
Hubert Kario


From nobody Thu May 29 12:34:21 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566251A04F1 for ; Thu, 29 May 2014 12:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye_hVEQSSGSC for ; Thu, 29 May 2014 12:34:19 -0700 (PDT)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E541A0225 for ; Thu, 29 May 2014 12:34:19 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id um1so836619pbc.18 for ; Thu, 29 May 2014 12:34:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gjJz6l847JL9FpW7mYnS9WhlKUU0eVQfTdhBFXouGRQ=; b=WIODgPDZa4ub27GrPchX9aEXz7x+X5vFuC0vgAAcN1h0VjnXm4PXMLjzmNAQ2BP5EY 5jgVCm7SB+o9YV1GveeQcEm+u6RkK9v5BSQsRYWDQ7PLtvwc95IStZSC1Iitsf9ANIvi CTHjsgMWwfzF/m86uVcTRbA2GKP/if+A5FpVOLMaDS9hXPxml/TVKv8UoAQNMLbcCWk0 goUv8U+V7qP5/jY13iaF5P2RpK9gHuaHrjGbjXm3CYd66YXcGfezzYwCt01GkCRxOB0V DLx4wivkzdtu5Le68ELgwCiMmbypgjyBfln/itK8s/wo3b8ZfwPTLnPLTD1qYLEZWD4v l8jg==
X-Gm-Message-State: ALoCoQkCbTBWQcRwML02Sl32tCuB8L+ElN2fH8N9zMPUpCoCwU58zeHeoqi8JhspY1YhHhe+57KQ
X-Received: by 10.68.125.164 with SMTP id mr4mr11512056pbb.27.1401392054137; Thu, 29 May 2014 12:34:14 -0700 (PDT)
Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id ue3sm2548582pbc.49.2014.05.29.12.34.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 12:34:13 -0700 (PDT)
Message-ID: <53878BBE.8020606@nthpermutation.com>
Date: Thu, 29 May 2014 15:34:22 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp>
In-Reply-To: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dCa9wi8U9LHMsnygNpZ41x8NPrE
Cc: "tls@ietf.org" 
Subject: Re: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 19:34:20 -0000

On 5/27/2014 5:21 PM, Martin Rex wrote:
> Michael StJohns wrote:
>>
>> Continuing, the master secret *is* used explicitly as a MAC key
>> (finished message) and as a master key for a KDF (key expansion).
> Unless you're using a NULL encryption ciphersuite, the Finished
> messages _are_ encrypted, rather than exchanged in the clear,
> and there is a reason why the Finished message is truncated.
>
> For the two communication peers that are involved (TLS client and
> TLS server), the master secret is a shared secret.  For any attacker,
> the finished messages are not visible (encrypted).

Not really sure why this is relevant.  Are you arguing that the finished 
MAC isn't actually a MAC or the finished MAC isn't necessary if the 
handshake is encrypted, or isn't necessary if these messages are 
encrypted? Or that the key for the MAC isn't actually a key?

As a general comment, the security of the TLS handshake protocol 
shouldn't a) depend on the encryption of the handshake messages, or b) 
depend on the security of any part of the negotiated cryptographic suite 
except that specifically required for the handshake (and right now, 
that's only the PRF).  (e.g. I can't assume that the cipher suite isn't 
NULL for encryption when designing the security).

Encryption of the handshake is "nice to have" and "provides privacy for 
some elements of the handshake (e.g. certificates)", but isn't actually 
critical for the security (integrity/source authentication/key 
agreement/correctness/prevention of MITM attacks) of the protocol.


>
>> Seriously though - no.   Basically if you share it, it's no longer an
>> entropy pool, but a key.
> There is a necessity to share the master secret with your communication
> peer so that both can derive the same new secrets from it.
>

Hence my point that the master secret is a key, and not an entropy pool.

You've made a claim about the master secret (and the PRF) being more 
like an entropy pool.  Is there any literature to support your view?

Later, Mike






From nobody Thu May 29 13:19:24 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A341A06A0 for ; Thu, 29 May 2014 13:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level: 
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq96gGjJ3n0A for ; Thu, 29 May 2014 13:19:20 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB11A0699 for ; Thu, 29 May 2014 13:19:19 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s4TKJE9j001152; Thu, 29 May 2014 16:19:14 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Michael StJohns , "mrex@sap.com" 
Thread-Topic: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
Thread-Index: AQHPecPLJGkTKnHy+kWiJdcdR/Ip75tVKQIAgAAIEACAAAGvgIADBsAA///JWAA=
Date: Thu, 29 May 2014 20:18:49 +0000
Message-ID: 
References: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp> <53878BBE.8020606@nthpermutation.com>
In-Reply-To: <53878BBE.8020606@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [172.25.177.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3484225124_11850064"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14,  0.0.0000 definitions=2014-05-29_06:2014-05-29,2014-05-29,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405290250
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nn8mgKgZmOBz9q3360NWAGk9c8A
Cc: "tls@ietf.org" 
Subject: Re: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 20:19:21 -0000

--B_3484225124_11850064
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit

>>There is a necessity to share the master secret with your communication
>> peer so that both can derive the same new secrets from it.
>>
>
>Hence my point that the master secret is a key, and not an entropy pool.


*Shared* entropy *is* a key.  :-)

--B_3484225124_11850064
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP
8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5
pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi
ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj
akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu
ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB
BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3
FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi
BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3
EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM
AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T
eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m
1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2
BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ
NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk
u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB
BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww
CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi
b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF
vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9
RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP
6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA
mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk
xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm
DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD
VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s
bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu
ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy
bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G
CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB
AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG
SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L
TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ
cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT
iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r
/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf
MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE
ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM
TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC
VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG
A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO
KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z
Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD
2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo
bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM
nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU
Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+
G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf
gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO
1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa
a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn
rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK
PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU
IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y
MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV
BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX
Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4
YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C
PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2
QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D
1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB
kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud
IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC
hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6
Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB
BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE
VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ
BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ
iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw
7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8
c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt
DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX
X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE
BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET
MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG
SIb3DQEJBDEiBCAci/5t8UOATuswX9GWa7z/4VEjJqe5puuBZjpel2jhGjAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjkyMDE4NDRaMA0GCSqGSIb3
DQEBAQUABIIBABcuLSrLJ6Ltro8XIH5bcK1jjXfsMynWgHaMcc35i3FLwQjlS5nJDS1bS3/1
/8qAqmg3nQu5bfKwKFKaWsNcF6B/zhVLNwIyggJtvafn1yPu97pvhZ8lI1NpcMcpLVmcl7dA
sLI55+hjTRQuXGNLmsMkkWDOT17g3VwP9kHbez33amk7uOumAQ06iMX/qty72cPadMQ8qDmE
jU6PtmBju/xhQs7xC1tusEZex38rglAIl8l1Z1a9CqJVr7/5srbKFYOOLJMv32F4jlfZ9gko
TtAFKAbgsCKacU7Eq3C/HG7m+Gfw2C3Hr1bmh43Cl2f841w6nQDe4gpGqkOAfqGwAf8=

--B_3484225124_11850064--


From nobody Thu May 29 14:34:17 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE61A0262 for ; Thu, 29 May 2014 14:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level: 
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4ocxFQn_ahZ for ; Thu, 29 May 2014 14:34:14 -0700 (PDT)
Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAF01A02CE for ; Thu, 29 May 2014 14:34:14 -0700 (PDT)
Received: by ore.jhcloos.com (Postfix, from userid 10) id 901721DDA8; Thu, 29 May 2014 21:34:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401399249; bh=vQAcP9CUUHrDI6mHObfkXF558ePankN1yCW4xzvy9vU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=eSByJtZGtE7DlErOKBUJmaQJixVhcdufAuY8okV8m7/CN9ZTrMj99WWmoff5hDW9q ccaXXe8CCOTczlw+pSvZU8NHkZ/zS2LN0TvNeCpVy3GjFnL62tmq3mjNO6tS6xNF5b CYl0lCRRN21R6rDD7VdYx8cmrvDKTSko6Ez6ADKo=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 74E8F6001E; Thu, 29 May 2014 21:28:02 +0000 (UTC)
From: James Cloos 
To: Hubert Kario 
In-Reply-To: <739427058.16557109.1401382793847.JavaMail.zimbra@redhat.com> (Hubert Kario's message of "Thu, 29 May 2014 12:59:53 -0400 (EDT)")
References:      <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com>  <739427058.16557109.1401382793847.JavaMail.zimbra@redhat.com>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2014 James Cloos
OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Thu, 29 May 2014 17:28:02 -0400
Message-ID: 
Lines: 15
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Hashcash: 1:30:140529:hkario@redhat.com::e3M2GjwPe8vYwUqV:0000000000000000000000000000000000000000000oKJu7
X-Hashcash: 1:30:140529:martin.thomson@gmail.com::r4zYp3j9CA5GSgcN:0000000000000000000000000000000000000vmfq
X-Hashcash: 1:30:140529:geoffk@geoffk.org::+XXLt8lBghbkY1K3:000000000000000000000000000000000000000000017Vhd
X-Hashcash: 1:30:140529:tls@ietf.org::3kW0ePDA01mghE3h:0000ApeMX
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m-lhPwXm7erHzWM9amLY3I7E0aE
Cc: Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 21:34:15 -0000

>>>>> "HK" == Hubert Kario  writes:

>>> Transferring 64GB of data with TLS over loopback on a relatively modern
>>> machine (even without AES-NI) takes less than an hour. I wouldn't
>>> call it going to great lengths to test.

Did you mean something other that GB there?

150Mbit/s is a bit slow for loopback. ☺

64GB (31 bits of 256-bit blocks) over loopback should take 3-5 seconds.

-JimC
-- 
James Cloos          OpenPGP: 0x997A9F17ED7DAEA6


From nobody Thu May 29 15:19:10 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023861A0195 for ; Thu, 29 May 2014 15:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.899
X-Spam-Level: 
X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgyFk555yp0M for ; Thu, 29 May 2014 15:19:04 -0700 (PDT)
Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B8C1A0697 for ; Thu, 29 May 2014 15:19:04 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id y13so215161pdi.16 for ; Thu, 29 May 2014 15:19:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=KxXAy62oacfHezq7gs4D6elEixacg9eMcN00bZAnMAk=; b=OhyFf1F4iqmAnW1l/U2eWHPAoNBfzaj6li2aZ+jYeq7WG/J9j01EqvPb7wdELyxKnc pVuj6qWWZyZK23zVeTs3Dh3YIS3Ymd+ldxywdVp4np65IKdMLIXVum67rrMjNzeK5pVT HYy5Ex/v9HbhwqXJpUP4DfmdzxGroUIXxGKX7nuowdqGs8TIbzoDhXdIUNB9Sng+tIAV +17kDYtLrr/A9WmP2dcEGo3AlqZEgNXR3GBtlRL7Nnn283G+5OFaiJ+HVg4rQ/k6fM4Z 0mDnPGslBRFubpEguno9sAgUWXQ3nQsn7Gug4nTJNQl/gzEvcHaedUqSotgpYX92raxl LYuQ==
X-Gm-Message-State: ALoCoQnNQXr9B2xSOQ7O49e2GFns8SMr0vJjjtRhdVvNQvw+6OVkZglZzufgru4w8F+lkhNJtN/e
X-Received: by 10.68.130.38 with SMTP id ob6mr12420858pbb.141.1401401940084; Thu, 29 May 2014 15:19:00 -0700 (PDT)
Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id pv4sm8809973pac.14.2014.05.29.15.18.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 15:18:59 -0700 (PDT)
Message-ID: <5387B25B.8050903@nthpermutation.com>
Date: Thu, 29 May 2014 18:19:07 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Blumenthal, Uri - 0558 - MITLL" ,  "mrex@sap.com" 
References: <20140527212125.17AF81AD1D@ld9781.wdf.sap.corp> <53878BBE.8020606@nthpermutation.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080606050902050703080905"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3_lxmPNw_NgGeR5sjRH-vDHa9ro
Cc: "tls@ietf.org" 
Subject: Re: [TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 May 2014 22:19:07 -0000

This is a multi-part message in MIME format.
--------------080606050902050703080905
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/29/2014 4:18 PM, Blumenthal, Uri - 0558 - MITLL wrote:
>>> There is a necessity to share the master secret with your communication
>>> peer so that both can derive the same new secrets from it.
>>>
>> Hence my point that the master secret is a key, and not an entropy pool.
>
> *Shared* entropy *is* a key.  :-)

Shared *data* may be a key.  A key may have no entropy at all. (e.g. 
passwords for PBE, public keys for identity based public key systems, 
most PINs etc, your safe combination - really, your marriage date?).

Neither of the following statements is true:

    A key is always shared entropy.
    Shared entropy is always a key.

Then there's the fact that "shared entropy" is probably an oxymoron.  
Entropy is "lack of order or predictability", or in thermo "a measure of 
disorganization of a system" and "shared entropy" is there so that 
multiple entities can predictably come up with the same "unpredictable" 
values.

Going back to the origin of this discussion, the premaster and master 
secrets are "keys" - they may be other things, but they are always 
"keys" because without knowledge of those pieces of information you may 
not repeat the functions keyed by them and get the same answers.  (Look 
up many definitions of "key" and you'll find this general concept).  
Martin's assertion that the TLS master secret is not a key is ... 
unsupported by the facts.  Thinking about it as an entropy pool is 
misleading.

Later, Mike

http://niccs.us-cert.gov/glossary#letter_k
> key:
>
> Definition: The numerical value used to control cryptographic 
> operations, such as decryption 
> , encryption 
> , signature 
>  generation, or signature 
> verification.
>

http://jproc.ca/crypto/terms.html
> *Key* - Information (usually a sequence of random or pseudo-random 
> binary digits) used initially to set up and periodically change the 
> operations performed in crypto equipment for the purpose of encrypting 
> or decrypting electronic signals, for determining electronic 
> counter-countermeasures patterns (e.g., frequency hopping or spread 
> spectrum), or for producing other key. "Key" has replaced the terms 
> "variable," "key(ing) variable," and "cryptovariable." 

http://en.wikipedia.org/wiki/Key_%28cryptography%29
> In cryptography , a *key* 
> is a piece of information (a parameter 
> ) that determines the 
> functional output of a cryptographic algorithm 
>  or cipher 
> . Without a key, the algorithm 
> would produce no useful result. In encryption 
> , a key specifies the 
> particular transformation of plaintext 
>  into ciphertext 
> , or vice versa during 
> decryption . Keys are also 
> used in other cryptographic algorithms, such as digital signature 
>  schemes and message 
> authentication codes 
> .

http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/appendix-b-glossary.htm
>
> *key*
>     A string of bits used widely in cryptography, allowing people to
>     encrypt and decrypt data; a key can be used to perform other
>     mathematical operations as well. Given a cipher, a key determines
>     the mapping of the plaintext to the ciphertext. See also
>     distributed key, private key, public key, secret key, session key,
>     shared key, sub key, symmetric key, weak key. 
>

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
> Cryptographic key
> (key)
> A parameter used in conjunction with a cryptographic algorithm that
> determines its operation in such a way that an entity with knowledge of
> the key can reproduce or reverse the operation, while an entity without
> knowledge of the key cannot. Examples include:
> 1. The transformation of plaintext data into ciphertext data,
> 2. The transformation of ciphertext data into plaintext data,
> 3. The computation of a digital signature from data,
> 4. The verification of a digital signature,
> _*5. The computation of an authentication code from data*_,
> 6. The verification of an authentication code from data and a
> received authentication code,
> _*7. The computation of a shared secret that is used to derive keying*__*
> *__*material.*_




--------------080606050902050703080905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 5/29/2014 4:18 PM, Blumenthal, Uri -
      0558 - MITLL wrote:

    

    

      

        

          
There is a necessity to share the master secret with your communication
peer so that both can derive the same new secrets from it.



        

        
Hence my point that the master secret is a key, and not an entropy pool.


      

      

*Shared* entropy *is* a key.  :-)


    

    

    Shared *data* may be a key.  A key may have no entropy at all.   
    (e.g. passwords for PBE, public keys for identity based public key
    systems, most PINs etc, your safe combination - really, your
    marriage date?).

    

    Neither of the following statements is true:

    
A key is always shared entropy.

      Shared entropy is always a key.

    

    Then there's the fact that "shared entropy" is probably an
    oxymoron.  Entropy is "lack of order or predictability", or in
    thermo "a measure of disorganization of a system" and "shared
    entropy" is there so that multiple entities can predictably come up
    with the same "unpredictable" values.

    

    Going back to the origin of this discussion, the premaster and
    master secrets are "keys" - they may be other things, but they are
    always "keys" because without knowledge of those pieces of
    information you may not repeat the functions keyed by them and get
    the same answers.  (Look up many definitions of "key" and you'll
    find this general concept).  Martin's assertion that the TLS master
    secret is not a key is ... unsupported by the facts.  Thinking about
    it as an entropy pool is misleading.

    

    Later, Mike

    

    http://niccs.us-cert.gov/glossary#letter_k

    
key: 
      
Definition: The numerical value used to control cryptographic
        operations, such as decryption, encryption, signature
        generation, or signature verification. 

    

    

    http://jproc.ca/crypto/terms.html

    
Key - Information (usually a sequence
      of random or pseudo-random
      binary digits) used initially to set up and periodically change
      the operations
      performed in crypto equipment for the purpose of encrypting or
      decrypting
      electronic signals, for determining electronic
      counter-countermeasures
      patterns (e.g., frequency hopping or spread spectrum), or for
      producing 
      other key. "Key" has replaced the terms "variable," "key(ing)
      variable,"
      and "cryptovariable."
    

    

    http://en.wikipedia.org/wiki/Key_%28cryptography%29

    
In cryptography, a key is a piece
      of information (a parameter)
      that determines the functional output of a cryptographic algorithm
      or cipher.
      Without a key, the algorithm would produce no useful result. In encryption, a key specifies the
      particular transformation of plaintext
      into ciphertext, or vice versa during decryption. Keys are
      also used in other cryptographic algorithms, such as digital signature schemes and message authentication codes.

    

http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/appendix-b-glossary.htm

    

      

        
key

        
 A string of bits used widely in cryptography, allowing
          people to encrypt and decrypt data; a key can be used to
          perform other mathematical operations as well. Given a cipher,
          a key determines the mapping of the plaintext to the
          ciphertext. See also distributed key, private key, public key,
          secret key, session key, shared key, sub key, symmetric key,
          weak key.
        

      

    

    

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

    
Cryptographic key

      (key)

      A parameter used in conjunction with a cryptographic algorithm
      that

      determines its operation in such a way that an entity with
      knowledge of

      the key can reproduce or reverse the operation, while an entity
      without

      knowledge of the key cannot. Examples include:

      1. The transformation of plaintext data into ciphertext data,

      2. The transformation of ciphertext data into plaintext data,

      3. The computation of a digital signature from data,

      4. The verification of a digital signature,

      5. The computation of an authentication code from data,

      6. The verification of an authentication code from data and a

      received authentication code,

      7. The computation of a shared secret that is used to derive
          keying

        material.

    

    

    

  


--------------080606050902050703080905--


From nobody Fri May 30 02:36:22 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4042F1A078F for ; Fri, 30 May 2014 02:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZQAzDtk_cEy for ; Fri, 30 May 2014 02:36:10 -0700 (PDT)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by ietfa.amsl.com (Postfix) with ESMTP id 650ED1A03D3 for ; Fri, 30 May 2014 02:36:10 -0700 (PDT)
Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4U9a3Wh019344; Fri, 30 May 2014 05:36:03 -0400
Date: Fri, 30 May 2014 05:36:03 -0400 (EDT)
From: Hubert Kario 
To: James Cloos 
Message-ID: <447419780.17071094.1401442563129.JavaMail.zimbra@redhat.com>
In-Reply-To: 
References:     <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com>  <739427058.16557109.1401382793847.JavaMail.zimbra@redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.5.82.12]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922)
Thread-Topic: Proposed text for removing renegotiation
Thread-Index: U8N83OiZXy6RelEbcThfWtdpJCttUg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lP4JamIAr3BVMovzeBzAWSUKyUA
Cc: Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 May 2014 09:36:14 -0000

----- Original Message -----
> From: "James Cloos" 
> To: "Hubert Kario" 
> Cc: "Martin Thomson" , "Geoffrey Keating" , tls@ietf.org
> Sent: Thursday, May 29, 2014 11:28:02 PM
> Subject: Re: [TLS] Proposed text for removing renegotiation
>=20
> >>>>> "HK" =3D=3D Hubert Kario  writes:
>=20
> >>> Transferring 64GB of data with TLS over loopback on a relatively mode=
rn
> >>> machine (even without AES-NI) takes less than an hour. I wouldn't
> >>> call it going to great lengths to test.
>=20
> Did you mean something other that GB there?
>=20
> 150Mbit/s is a bit slow for loopback. =E2=98=BA

It's not slow for AES though.

That was the example of slowest performance for this, in a full functional =
test -
where the application is in production configuration. That is, it does ever=
ything
from certificate verification to AES-GCM crypto, all in software on a few y=
ear
old hardware with encryption and decryption running in parallel.

With AES-GCM done in hardware (e.g. AES-NI) on a multi core CPU, the test s=
houldn't
take more than 10-15 minutes.
--=20
Regards,
Hubert Kario


From nobody Fri May 30 10:57:51 2014
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0981A09D3 for ; Fri, 30 May 2014 10:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level: 
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csTBfgeG4RxQ for ; Fri, 30 May 2014 10:57:47 -0700 (PDT)
Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E3B1A036A for ; Fri, 30 May 2014 10:57:47 -0700 (PDT)
Received: by ore.jhcloos.com (Postfix, from userid 10) id BF0F51DF86; Fri, 30 May 2014 17:57:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401472662; bh=4cIIpejxu2PkQxMZeCcWeBkDuNT6qZaHT9cIOxvcTIs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hVcDRyrovFkzRR9KtY6NH+XqAfPdSK1jdV18Onu9EitmqxbcGicDEmSqlt2TVZtHx ihPoMjWoyySd58plBGoZVdfIWNUf+AakaMJESQwd/8oFAzWn5dlNd/ziNhdEF+o9n6 TyoPsOuaXUrm3Lfp7RMRGj1zdNmHPKb6sheReR+s=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id DCAD46001E; Fri, 30 May 2014 17:45:26 +0000 (UTC)
From: James Cloos 
To: Hubert Kario 
In-Reply-To: <447419780.17071094.1401442563129.JavaMail.zimbra@redhat.com> (Hubert Kario's message of "Fri, 30 May 2014 05:36:03 -0400 (EDT)")
References:     <1414735395.16311772.1401366314379.JavaMail.zimbra@redhat.com>  <739427058.16557109.1401382793847.JavaMail.zimbra@redhat.com>  <447419780.17071094.1401442563129.JavaMail.zimbra@redhat.com>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2014 James Cloos
OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 30 May 2014 13:45:26 -0400
Message-ID: 
Lines: 13
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:140530:hkario@redhat.com::ihU8zTbryS6T4JJM:0000000000000000000000000000000000000000000AF5Wj
X-Hashcash: 1:30:140530:martin.thomson@gmail.com::VMD+HmToifWB/F+c:000000000000000000000000000000000000GtYwJ
X-Hashcash: 1:30:140530:geoffk@geoffk.org::MGqu0rnZ0JHqEDOT:0000000000000000000000000000000000000000000fjoYW
X-Hashcash: 1:30:140530:tls@ietf.org::Qp1bpLjpLi9RyCW7:00003R0hs
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/08C7K6nBAc68o_d03MUOtoUlmXg
Cc: Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 May 2014 17:57:50 -0000

>>>>> "HK" == Hubert Kario  writes:

HK> That was the example of slowest performance for this, ...  all in
HK> software on a few year old hardware with encryption and decryption
HK> running in parallel.

I see.  The post gave the impression that it were intended as an example
on more recent hardware.  Although even a K10 is closer to 150 MB/s than
150 Mbit/s.

-JimC
--
James Cloos          OpenPGP: 0x997A9F17ED7DAEA6